Steve:
Hello, everybody. Glad you could join us today. Customer projects in the broadcast world, it can be very challenging, but there’s some key development practices that will help you with your next project to be a success. Today, we’ll go over some of those practices by doing a case study on a recent project we did with PBS to update their Warning Alert and Response Network System, otherwise known as PBS WARN. We’ll finish with a Q&A session, so if you have any questions along the way, please add them to the chat, and we’ll answer them all at the end. I’m Steve, I’m here today with Jess. Hello, Jess, how are you doing?
Jessica:
Hey, Steve. I hope you’re doing well, and welcome everybody. Thanks for joining us. I’m really excited for today’s webinar, very informative.
Steve:
Great. So, I guess first thing, let me just take a moment to explain what is the WARN system? I’m sure everybody’s familiar with the alerts you get on your phone, your Amber Alerts, Silver Alerts, some Weather Alerts. And the way that typically works is the messages get sent over the internet to the wireless carriers, who will then send it out to cellphones as needed. But what happens if the internet goes down? What’s the backup system? Well, you’ll probably be surprised to learn that it’s actually the nationwide footprint of the PBS member stations.
Steve:
And the way this works is the messages are also sent by government entities, such as FEMA, to the PBS satellite uplink. And from there, they go up to the satellite, which goes out to all the PBS stations. And then, from the PBS stations, when it comes in, with the PBS WARN system, we developed, does is it’ll take those messages out of the satellite feed, and then inject them into the PBS over-the-air feed. So, now you have this nationwide over-the-air system, which is sending out the alert messages, so the different wireless carriers can get the messages, and then deliver them out to your phone.
Steve:
So, that’s just kind of a little bit of an idea of what the wireless alert system does there, or what the PBS WARN system does. A few of the key requirements which was needed for the system. One, it needed to do opportunistic injection. Basically, what that means, is that it uses null packet replacement. You don’t want to affect the transport stream. So, you replace null packets with the wireless alert messages. On the case that there is no… null packets are very few, especially in cases where people are using stat boxes to kind of really squeeze as much out of the risk capabilities in there that it will actually… First their null packets and we’ll use the IT and ETP PIDs. And in the worst-case scenario, if none of those are available, either there is also a user-configurable PID, the spatial set, that it can use to do the alert messages. It also has to be fail-safe and fail-over.
Steve:
And what that means is with fail-safe, it needs to basically fail gracefully. If something happens, you don’t want the system to suddenly go off the air, so it needs to fail gracefully. But in addition to that, it should also fail-over to a backup redundant system. So, not only does it fail and that caused the issues, but if you still get the alert messages sent with because it will fail-over to a backup system. It also needed to support SNMP messaging. It also needed a single unit solution. One of the things PBS wanted to change from the original warrant system is that it was made up of individual components. So, it took up a lot of Rackspace, just a lot of different user interfaces you had to use to talk to it. So, they wanted to get it trimmed down to just one device. And it also needed to support IP in and IP out.
Steve:
Since a lot of station is now transitioning to an all-IP infrastructure. Also needed a lot of alarm indicators, all the different things, that different message type errors. If there are any issues with the power supply, the fans, communications between the cards. So, it had a very robust alarm system, which will also manage the glow bar on the front panel of the open gear frame. And one of the key things, which is kind of unique about this PBS project, is it really had to be flexible in function. One thing I didn’t really know until I got involved in this project was that PBS doesn’t actually own the PBS stations.
Steve:
They’re all independent member stations. And just kind of made this very challenging, but also very a fun project to do because each PBS station is different. Some maybe using ASI, some maybe using IP, somebody’s using SMPTE 310 and the other use combination of all three. And also, where they placed the WARN system. It could be different. It could be before the multiplexer, after multiplexer. Sometimes there may be a need that there is no incoming stream to inject into, so we have to generate our own null packets to be able to inject WARN messages into. So, that kind of made it a very interesting project, in that sense.
Steve:
So, now let’s talk a little bit… Oh, actually, one thing I was going to say about that, about PBS stations, which is kind of a phrase I kind of learned in this project is, “If you’ve seen one PBS station, you’ve seen one PBS station.” Because everyone’s unique, you’re going to run into different things at each station because they’re all independent. Now, let’s talk a little about the process of working with PBS WARN team, and some of the keys to a successful custom project. So, once we were awarded the project, the first thing we did was spent about three months hammering out the statement of work. It was a long process, if you’re trying to kind of think of everything which needs to be covered, everything that used to do and try and think of every potential thing which could happen. And another thing which makes that process a long process is because it’s such a big project and scope that it has to be approved by all the C-level executives at PBS.
Steve:
It’s got to go through our legal team, PBS legal teams. There’s just a lot of behind-the-scenes involvement with other people, as well. So, because of that, one of the things we built into the statement of work is sort of pre-approved engineering hours. Because one thing we know from experience is you come up with a statement of work, and you think everything’s great, but once you actually start doing it, you start realizing, “Oh, we didn’t think of this.” That we’ve got to account for this possible thing. Or, you kind of get everything done, and you’re kind of looking, and it’s just not working the way you envisioned it. You have to make modifications, so it’s good to add this flexibility in there and what allowed us to do since these engineering hours were already pre-approved. When you came across these situations, all we needed to do was to get approval from the PBS WARN team to move forward with it.
Steve:
We didn’t have to go through and get everything re-approved by all the C-level executives go through legal against that really helps as you go along in the process if you have some flexibility built into the statement of work. Next thing, once we had the statement of work, is you want to break that up into small manageable tasks and milestones, and then have some sort of a project management software. Here at D2D, we use Jira, so it really helps when you break these tasks down. You can assign them to the engineering team and really allows you to manage the project to make sure everything’s staying on track. Along those ways, one of the most important things you want to do, in a project of this scope, is to have a very iterative and agile process. Because one thing you don’t want to do is kind of work out this statement of work, and then you go off for six months and develop it, because even if you do it exactly as described in the statement of work, it’s not going to be what the customer ultimately wanted.
Steve:
As I was saying before, there would be things that you didn’t think of, you don’t include, or things that just didn’t work the way you thought. A good example of that, for this project, was once we had things kind of functioning and we started kind of doing testing, we came across the issue of rain fade, which is quite common in a lot of stations throughout the country, where you have, due to different falling weather, rain, snow, that the satellite feed will come and go.
Steve:
The way the system was originally designed is, it’s supposed to receive a heartbeat every 30 seconds. So, if this is a couple of heartbeats, it would think, “Oh, something’s wrong.” And it will switch over to the redundant system. But in areas where you have rain fade, that’s going to happen quite often. So, we had to kind of come up with some ways to kind of better determine if it was rain fade or if there’s really an issue. One of the things we did was, if we miss a couple of heartbeats, but we can still talk to the satellite card, we would think it would be a good indication that it was just a rain fade issue.
Steve:
And we’d wait a longer time period of missed heartbeats before we actually switched with… We had to put a warning out at that time, but it would be a longer time period, which is configurable, but defaulted to around 10 minutes before it actually thinks there was a true failure and switch over to the backup system. Now, once you have your system between the customer and the vendor, you think you have a system which is good and ready to go, it’s really key to get it out to some beta stations in the field and get some real-world testing on it. Because one thing you will find is, if one is in a different environment, things may work a little different than they do in the lab. And another thing is, ran across this a lot in years of being a developer, as you’re developing things, you sort of have a preconceived notion in your head of how it’s going to work, how people are going to use it.
Steve:
And what you realize is, once it gets out there, people can do things you’ve never even thought of. They’re going to try certain things. It’s like, “Why would somebody try that?” But it’s a new system, and they’re just trying different things. And so, it’s really good to kind of get it out there and kind of get a good feel for how people are going to truly use it in the field and see what changes you may have to make because of that. Then, once it’s finally deployed another key aspect is support. And I’ll let you talk a little bit about that, Jessica.
Jessica:
Sure. Thanks, Steve. Yeah. Well, obviously, when you’re deploying something that really has no history to almost 200 stations, there’s obviously going to be a lot of support. And the thing about support that we did on this project, and what I feel is always the best way to do it, is to document things from the beginning. We started the manual based on the statement of work on day one. And then, we handed it over to PBS and we sort of wrote it in collaboration together and it worked out real well. And the other thing we did is we wanted to make it really easy for people to get ahold of us. So, if they have a problem, we gave them a special phone number. We gave them my personal emails and the support personnel email. So, for some reason I’m busy, they could get ahold of somebody else.
Jessica:
We also gave them a web portal on our website, so they could go there and get all the latest manuals, the latest firmware. There was a frequently asked questions on there. And then, at the same time, they could either submit a ticket through there, through our Jira, or that he’d get ahold of us through email. So, we made it really easy to track all the problems. And then, in most cases, I think, because of the beta station rollout, we were able to fix the problems pretty much before they came, not in every situation, but in most situations, we knew about the problems before they were reported.
Jessica:
So, it was kind of nice to say, “Oh yeah, okay. Well, we know about that. We weren’t caught broadsided very often by problems that came out of nowhere.” And so, that was the great thing is, as I think, if you’re doing a special project for a station group or somebody, start your paperwork early, start the manual early, start thinking about customer support long before the product rolls out, because you’re going to need it. And in this situation, more was less. So, the more we gave people information advance, the less the phone rang, and honestly the phone didn’t ring very much. It’s been really good.
Steve:
Awesome. What about having sort of some webinars to kind of help stations be prepared?
Jessica:
Yeah, well, that’s exactly what we did, is we did a webinar with PBS. It was actually by PBS. They invited all of the PBS stations, and most people showed up, and we’re sort of able to give them a heads up, advance of here’s what’s coming, here’s what’s going to happen. And then, at that point, we were able to go through of all of our customer service applications and the best way to get ahold of us. And so, I think that put a lot of stations at ease during the rollout. I think it also put all of us at ease, too. We sort of established a rapport with everybody, in advance. And that’s also key, too. You don’t want to just surprise somebody with this new gear that they have to put in and not answer their questions upfront if you can. So, I think we did a good job on that.
Steve:
Great. Another kind of thing, as far as the support and ongoing development of the project, is just to kind of take that feedback you get from the customer base and use it to improve the system. So, in the case of PBS, it’s been out there about six months now and we get some good feedback from the customers, where all things are going great, but you always get those questions like, “Yeah, it’s working fine and everything’s good, but it would be really cool if it did this.” So, to kind of get that feedback. And so, we’re actually going to be here soon, sending out a kind of big release with some enhancements. We’re just letting them just use our ability type things where each of the system has two groomer cards in it. And it’s kind of nice that you can actually see the status of both groomers on one page, but now there are things that you can with a groomer.
Steve:
That card will actually go a little gray out to kind of indicate that it’s not talking or working. For the browser tabs, so just have an IP address, how we’ve changed it to, and actually has the cards name. So, just kind of a lot of usability things that once it gets in the field. People have suggestions of, “Hey, it’d be nice if it could do this.” So, it’s really important to kind of take that feedback and if all possible, try and get that rolled into a future release, that it really helps improve the system over time.
Jessica:
That’s a great point, Steve. You got to listen to your customers because they’re going to use your gear, not in a lab, but they’re going to use it in real-world situations. And listening to them makes it important to put out the features, and it’s especially nice when you do special projects to really put out a product that exactly what your customers need.
Steve:
Okay. So, kind of talking here about the keys to success for a project, some of those include… While it’s important to develop a detailed and comprehensive statement of work is should really build in some flexibility for things that you don’t anticipate, or things which don’t work in practice, the way you envisioned. Then, once you have that statement of work, you should break it down to smaller tasks, which can be easily managed and tracked. You should do an iterative process. You get that constant communication between the customer and vendor to ensure the project is on schedule and is meeting the customer’s needs, then follow that up with some beta testing.
Steve:
And then, the final thing is you always want to make sure you provide good quality support and it’s… Once the systems out there, it’s really just the beginning. Because, now, you got to make sure over the lifetime of the product that it’s meeting the customer’s requirements, and it’s also kind of build in enhancements and improve the system over time. So, next, I’d like to just give a quick overview of the WARN system kind of a little bit early to went over kind of what the requirements were. And just to kind of show you kind of what we came up with D2WARN. So, you have a slide there, Jessica.
Jessica:
I do. Yep, hang on.
Steve:
Just kind of get a little block diagram of the D2WARN system.
Jessica:
It’s opening. It’s opening very slowly. Sorry about that.
Steve:
That’s all right.
Jessica:
Here we go. All right.
Steve:
Okay.
Jessica:
Here we go.
Steve:
There we go. Okay. A block diagram is a D2WARN system, and basically, everything you see within the dotted line is actually included inside of a Ross OpenGear Frame. So, that’s one of the things we did, is to kind of really take all those five different components, which make up the original WARN system, is really condensing down into a single component, which is the Ross OpenGear Frame. And you’ll see, within the frame, we basically have two satellite cards which are integrated from Suncor and what they are doing, they’re supplying the groomer cards, which are the ones who are actually doing the work here. So, you can see the local over the airstream comes in, comes into the product primary groomer, it will then kind of take the alert messages from the primary satellite, inject them into the stream, and pass on to the backup groomer.
Steve:
And so, what the backup groomer will then do, if it seems that the primary groomer is not doing the insertion like it should be, it’ll actually take over from its own satellite receiver card and do the insertion. And then, we’ll kind of go out over the air. So, you can see here, this sort of takes them both the fail-safe and the fail-over. The fail-safe comes in the play where both these groomer cards have switches in them. So, if they’re to lose power or the card fails, that will just pass the ASI directly through almost as if it was a barrel connector. And then, the way the fail-over works, if either the groomers, if the primary groomer fails, the backup will take over.
Steve:
If the backup fails, it’ll just pass through the primary, and the primary alarm saying, “There was an issue with the backup groomer,” so that things can be replaced. And what’s really kind nice, is this system, with this fail-over, is you can actually take the opengear frame, pull the power on it, and then you won’t even see a glitch on air, it’ll just pass right through. So, that’s kind of good. The key things, probably the number one thing for PBS over everything, is not to cause issues with the over-the-air stream. So, it’s very important that if there is any failures, that it fails over gracefully. And if you want to go and stop sharing for a second, Jessica, I’m going to share real quick here, our system here, we have… Okay. Can you see that, Jessica?
Jessica:
Yeah, we got it. Looks great.
Steve:
Okay. So, what we’re looking at here is an actual WARN system running in our lab here. So, this gives you an idea of, as I told you before, it has to be in a lot of alarm capability, but shown here, we have our are two groomers at the same… What’s kind of nice, no matter which groomer you’re talking to, you actually get the status of both groomers. The two panels here shows both, everything’s green. That’s what you like to see. You see, we have all these different alarms for communications between the cards, power supplies, fans, all these types of things. So, if there are any issues… So, not only on this screen, you would see these alarm indicators would go, but this also would signal on the front of the actual opengear frame itself, that there is a white bar, which is normally blue.
Steve:
Then, if you give me a warning, so it’ll go yellow. And an actual alerts will actually turn the light bar to red. So, a lot of indications that if there is an issue with the system. And one thing we really tried to do here was trying to get a lot of information on one screen, but without also making it too cluttered. I think we did a pretty good job with that, so you can really get a lot of information here. And then, the one you guys talked about was the flexibility and functionality. So, if you go over to the configuration page, you can see there’s a lot of different roles that the system could be in. It’d be primary backup with no video.
Steve:
Then, these aren’t even showing all the different options if you have IP. So, there’s a lot of different ways this could be configured. It takes a lot of different flexibility to meet all the unique demands of different PBS member stations. It’s also kind of nice here. We tried to kind of make it as user friendly as possible, so we had a lot of these standard configurations built in that if just select one, it’ll automatically set these other fields for you, for that configuration. So, you don’t have to set it individually though. We do have an actual manual configuration, which will then allow you to change individual fields that’s kind of made it a lot more user-friendly with all the different types of configurations you have at different systems.
Jessica:
You know what I like about this, too, is the fact that you actually put the manual inside the browser. There was… Yeah, you took it down. But-
Steve:
I just took it out for you, Jessica, but I get that.
Jessica:
No worries. I just thought that was really slick to put the manual inside the browser. So, it doesn’t just lead you to a web page, it’s actually, you can download the PDF from inside the browser. So, that was really cool. And then, the other thing that helped us a lot, too, is the diagnostic button. If for some reason something does go sideways, then they call us. We can say, “Hey, do us a favor and send us a diagnostic package.” And with one click, the customer can download the package and send it to us. And so, that’s helped a lot for troubleshooting.
Steve:
Just a little thing, what that diagnostic package includes. It includes all the logs, all the configuration settings, just a lot of system information. So, basically anything we can think of as engineers, we kind of put into that thing, which may help us determine if there’s a problem, what’s the cause. There’s a lot of really good, useful information in there that if there is an issue, you can download the diagnostic package and get a good idea of what occurred.
Jessica:
Yeah. It’s been super helpful.
Steve:
And then, one thing I was going to point out, so not only does the manual downloadable right from the user interface, so are the meds. So, if you’re using any type of SNMP program and you want to kind of get the MIBs, so you can see the messages yourselves in your own system. You can download the MIB right here from the unit, as well.
Jessica:
Which that’s true. Yeah. That’s also a good point because they didn’t have to call us to get MIBs, which was really great to help the customer help themselves. All right.
Steve:
So, that’s kind of a quick overview of the D2WARN system, which is what we get developed to put out to all the PBS member stations. It was a really fun project. We really enjoyed doing it. In fact, we actually, here at D2D, that’s thing we really enjoy is doing custom projects. Throughout our whole history, we’re a very engineering-centric company. We kind of do all our own hardware and software, and we really enjoy that kind of getting down, roll up our sleeves with a customer, and say, “What do you need? How can we help you?” And really kind of come up with some unique solutions that really kind of help customers with their unique situations, and it really gives us a really good sense of satisfaction where we’re able to kind of help the customer and see that they’re able to kind of get done with what they need to.
Steve:
And we just have a lot of design experience in that area and andother thing too with us. Being a smaller company, we are very agile and very nimble, and we can kind of do a lot of very personal service. One thing with the PBS iterative process is we basically had weekly meetings for the last two years with PBS. And I think I was on every one of those calls. So, you really get this personal service. If something comes up and it’s a question of, “Hey, can D2D do this?” Or, “How can we do this?” That’s not, somebody who’s got to kind of go back and talk to their boss, who’s going to talk to their boss. And maybe a week later, you finally get a response from somebody who’s not even intimately involved, day-to-day, with the project. So, if you really get that personal service where you’re actually get that one-on-one contact with people who are actually doing that development. I think that’s a real big thing that we provide when doing these types of custom projects.
Jessica:
Yeah. That’s important. Being able to roll with the changes and not have a bunch of red tape in the way if you… I mean, everyone’s going to change their mind and also scenarios are going to come up after the fact where you have to be able to make the change and make the customer happy without having to go through 10 channels of red tape and, of course, get 15 signatures. I mean, basically, we were able to make decisions on the fly, and our twice-weekly meetings, we’re able to keep everybody abreast of all the issues in real-time. And so, that’s so important. And the fact that we’re here in the US, too, on the same time zone, also made support and everything a lot easier rather than going overseas for support.
Steve:
That’s definitely a good point, Jessica.
Jessica:
Thank you.
Steve:
Okay. So, that’s kind of the D2WARN project and, say, your D2D… We really excel at doing these types of custom projects, a project coming up that you kind of need some assistance with, of how to do that, we’d love to talk to you and help you out with that. And let’s turn it over in the audience and see if you have any questions that we can help you with right now.
Jessica:
Yeah, Steve, we’ve got a couple questions come in. Here’s the first one. “Have you done any other custom projects?”
Steve:
Sure. The history of D2D, we’ve done quite a few, actually. The first one was very early on in the company, Three Angels Broadcasting Network. They are a religious broadcaster. They’d come to us and they’re kind of using some of our basic technology. But the other thing that they needed to do was, they’re doing satellite distribution and they didn’t want each location decode and re-encode the system and use a lot of quality that way, the extra expenses of decoders and encoders. But the one thing they still need to do was have FCC compliance for emergency alert messages. So what we did, we came up with a system, which you mentioned became our D2 alert product, is you can actually take in conjunction with digital alert systems. We’ve taken their stream from the alert system, which will basically have an impact stream, which is texts on a background and associated audio.
Steve:
And what we’ll do is we’ll replace all the incoming programs with the alert message. And then, when the alert message comes over, we switch everything back. That gave Three Angels a very cost-effective way for them to be FCC-compliant with their emergency alert message system. And another one we did was somebody that’s kind of a little bit the opposite. In Mexico, there’s a situation where they were sending out, once again, satellite distribution. But in this case, they weren’t doing decode and re-encode to do some vocal insertion, but the issue they were having is they’re having their PCIP being generated at the uplink. Well, the problem is when you then, decode and re-encode, you lose on your piece of information, all your channel guide information. And we’ve been very cost-prohibitive to put a piece of equipment out in every location. So, they went away to still generate that uplink, but not lose it when they did their local origination.
Steve:
So, what we came up with our system is we’re able to take in on our end. Yes, I want input. We take the satellite feed, we’d strip off all the alert messages, send it back out our ESI1 output for the local origination. Then, once all that was done, we passed back through into our second input where we had basically take the guide information and then put it into the post-local origination, which, and then, go out over it into the transmitter. So, it was kind of a nice way that we could keep their piece of information through the local origination process.
Jessica:
Oh, those customers still have those systems running, too, by the way. We hardly hear from them unless, for some reason, they forgot a password or something. So, I mean, that’s always a good sign. 10 years later, they’re still humming along. So, that’s really great. The next question, “Any particular challenges that you’ve had to overcome doing these special projects?”
Steve:
Sure. Kind of a good example with this particular PBS project is, one thing that PBS was trying to stay away from is having to use in Java because you know Java has a lot of issues. You got to make sure you got the right job, a virtual machine on your project, on your computer. And it can just be a bit of a headache. Especially, when you have this unique system with PBS, where every member station is independent. It’s not like, “Hey, all the stations are all running this version of Windows.” So, it’s a lot the user do, a single update to everybody. Every different station is unique. So, they really want to stay away from having to depend on Java, which was no problem for our cards because we were browser-based but what we ran into an issue is with this dashboard for the opengear frame.
Steve:
So, if, at all possible, they were trying to make it where dashboard is optional. Sure. If you have a dashboard and you like using it, great. But a lot of these stations, this is the only opengear frame they have. And they didn’t want to have to be a requirement that they have to let them a dashboard to kind of set the IP address of the frame and then those kinds of things. So, it was a challenge, but there’s a lot of fun to kind of really get in there and all the different types of protocols for the opengear frame.
Steve:
We worked with Ross to kind of get into some of these protocols that we can sort of basically, control the frame ourselves. So, you can actually, from our user interface, set the opengear frame, IP address, gateway. Then, the way that we were pulling the status of the frame, we’re getting the frames, the status for the power supplies, the fans. So, if anything goes wrong with the frame, it’ll actually alarm within our user interface. So, that took a lot of work to kind of get that all worked out and functional, but it’s kind of things we enjoy doing, here, at D2D.
Jessica:
Yeah. It was really neat. It was really kind of cool the way that you just use the canvas technology to work within the dashboard, so it can be done either way. I thought that was really impressive. Let’s see, we got one more question here. “How big of a company do you have to be to have a special project done?” Can you be-
Steve:
A lot, depending on kind of what you want to have, what you want to do, and sort of what the budget is. So, if it’s only a unit or two, you can’t really do a big project, but we also do a lot of just with customers, which only have one or two units. They’ll come to us and say, “Hey, it’d be really nice to do this.” And if it’s not something which involves a lot of work or it’s something like, “Oh, this would be really cool.” But all our customers would like this, so we’ll try and really work with people and, if possible, get that feature in. When it comes to a project, the scope of PBS, you do need some scales because there is a lot of engineering costs involved. So, if you don’t have that something like PBS, with 180 member stations, something of that scale to amortize the cost of development across a lot of units, that does become a lot of cost-prohibitive if you just have a handful of means to do something of that scale.
Jessica:
Sure. But you don’t need to be a multi-billion dollar company to come to us and say, “We have the special situation.” I find that a lot of things, as television evolves, a lot of people have these special situations where they’re doing this or that. And there’s a lot of the repack, obviously, sent a lot of people into different corners to do different things and people are getting pretty smart with engineering off-the-shelf. But in a lot of cases, I think you could save money and time by just having somebody do a special project for you if you’re rolling out to several stations. So, you don’t need a multi-billion dollar company,
Steve:
We can definitely do a lot of work with the smaller companies, which just have a handful of units.
Jessica:
Right. Fantastic. Oh, great. I don’t see any other questions, I guess, unless somebody else has one, we can… If anything else comes up, it looks like that was about it.
Steve:
I’m trying to say something else. Give it another minute for…
Jessica:
Let’s see if anything else… I’m saying, but it looks like, Oh, that’s it. All right.
Steve:
Okay. Yeah. It looks like that’s it for the question. I enjoyed this check with everybody today. And, once again, if you have projects coming up that you would like to talk about, we’d be happy to hear from me. You can contact either Jessica or myself. And with that, we’ll say goodbye and hope everybody a great day.
Jessica:
Absolutely. Thanks everyone for joining. Appreciate it. Talk to you soon. Bye, for now.
