Matt:
Hello, and welcome to the show brought to you with the support of media proxy. Today. We’d like to welcome Steve doll from D two D technologies. Hi, Steve. Welcome to the show.
Steve:
Oh, thank you, Matt and Simon. Thank you for having me here today.
Simon:
It’s good to see you. So, Steve, we’re going to be talking about, uh, PBS war today. Um, we’re going to come onto that in just a minute before we get started. Tell us a little bit about D2D and what you do.
Steve:
Sure. So D2D technologies, we’ve been around for almost 20 years. We have a background in multiplexing and some of the areas, in addition, multiplexing we do is, um, yeah, EES insert that’s an emergency alert system, insertion program guidance insertion also do a lot of sending transport streams around the country using the public internet, using the SRT protocol.
Matt:
Okay, great. Yeah. So brings us neatly then onto, onto the PBS warn system. What, what is it?
Steve:
Sure. So first, let me give you a little background of what PBS is for some of your international viewers who may not be aware. It’s a private nonprofit organization, uh, and partnership with almost 200 member stations around the country. And their mission is to provide high-quality content which educates, inspires, and entertains. They have a lot of great programming, including educational children’s programs, arts, and theater uh, documentaries, international programs. Remember when I was, young, that PBS was the first place I saw C great British show, such as Monty Python and, Dr. Who <laugh> and there you go. Fantastic. So they had, contacted us a couple of years ago, but a project there wanted to do called the PBS Warren system, a Warren stands for warning alert and response network, and basically what it is, is a backup to the emergency, uh, alert system, the wireless emerging, uh, alert system, those messages you get on your phone, uh, periodically.
Steve:
And the way that normally works here in the United States is the different government entities will send the messages over the public internet to the wireless providers, such as Verizon AT&T. And then they will basically send the messages out to whatever different phones are in that geographical area. But the question becomes what happens if the internet style, how do we get those messages out to your phones? That’s where PBS comes in. The alert messages will also go to the PBS satellite up link, where they’re sent to over satellite, to all the PBS stations around the country, where then each site, our D two Warren system will take the alert messages out of the satellite feed and inject it into the PBS over the air local, uh, local broadcast. And those yeah, uh, transmission be picked up by the, the wireless carriers.
Simon:
So what are the key requirements of the system of
Steve:
Sure. First of all, the one thing that was very important from the beginning that PBS really emphasized was do no harm, um, that, you know, we don’t wanna do anything to the regular over the air broadcast. So the first step we did with that, we use opportunist opportunistic injection, where we basically replace the null packets in the stream with the alert messages. So we don’t actually modify any of the data in the stream. It all had to be very robust. Uh, so we had kind of two modes of fail-safe, and a failover. Basically, what fails safe does is if there’s some sort of, uh, CATA, uh, issue where the, uh, the hardware just, uh, you know, loses power, or if some reason fails, it’ll still pass the signal through uninterrupted. We also had, uh, fail over, which is where if the, uh, primary inserter failed, it would fail over to a backup and also required SMP for communicating between the two servers and also for remote monitoring.
Steve:
This also needs to be a single-unit solution. This is where the Ross openGear was a key component of the system. So we’re able to put two of our insertion cards, plus two satellite cards, all within a single two UR frame, uh, supplied by, uh, the Ross openGear frame. I also had to have alarm and status indicators. And one of the other key functionalities that required was flexibility and functionality. As I mentioned before about PBS and something I didn’t realize until we were actually doing this project is PBS. Doesn’t actually own the stations. They’re all actually member stations. So each one is unique. There’s kind of a same within PBS that if you’ve seen one PBS station, you’ve seen one PBS station. So we had to handle different stations and ASI some IP, some 73, 10, some a combination of all three. So it’s quite a bit, different situations you had to be prepared for once the system was deployed.
Matt:
So, that’s interesting. What, was the process? What were the key steps in? Cause it sounds interesting getting, you know, warning signal up to satellite, and then down, via TV signal and then out into the mobile network, what’s the process how’d you start to, develop that kind of tool?
Steve:
Sure. So once we awarded the contract, we spent about three months, it’s earning out the statement of work, and it’s not only a technical process but also had to get upper management approval legal teams involved. Uh, and one of the things we did during that process, which became very, important was we built in some pre-approved funding for unanticipated features, modified functionality, cuz just sometimes, you know, you, you have this great plan, but once you start implementing realize it doesn’t quite work the way, you were expecting to. So it’s good to have this sort of built in so that when these situations came along, you didn’t have to go through that whole process. Again, of getting all the upper management involved legal teams involved. We only had to get approval from the PBS Warren team that we were working with.
Steve:
And once we had that at statement of work, the next key step was to break that up into task of milestones, which could be easily managed. We actually used the JIRA management system for our project management and it’s very important also to have an iterative process. We had weekly meetings and code updates with the PBS warrant team. We worked very closely. So that way they could see week by week, how the project was coming along, they could test it in their own. They had a demo unit at their site. They can be tested when we want along. So that way we can really keep track of that. We’re on schedule, it’s working, how they’re supposed to. And this is where kind of as saying the having that pre-built in funding is as we’re going along, we ran into this issue called rain fade. It’s not familiar with that.
Steve:
That’s with satellite reception rainy conditions, the signal can go in and out. And we first started testing that was causing it to fail over to the backup quite often. So we had to kind of go in and, and tweak things a bit so that we had a better, uh, understanding of when it was just rain fade and not an actual failover. So we wouldn’t fail the system over. Mm. And once you have a system ready to go, uh, it works great in our lab, works great in the PBS lab, but you really need to get it out in the real world. So we had about 10 stations, uh, lined up for beta testing and it was really nice cuz we had a mix of somewhere. I had I some more IP, some more hybrids. We can actually see the system working in different environments before we actually fully deployed it.
Steve:
Then after it’s deployed, uh, things aren’t over yet, cuz the really, probably the key thing is support. You know, making sure, you know, we’re always there, if there’s any issues, uh, we, we support it. We add enhancements. Uh, we actually, uh, it’s not once we got the, the system out and started giving feedback from the individual stations, um, they’d be like, oh, it’s working great. It’d be really nice that did this. We took all that feedback. And about six months after it was deployed, we did another update to kind of take in all that user feedback. So
Simon:
Steve, how, how important was the open gear element in the project?
Steve:
Critical. It’s kind of under saying that those kind of, one of the key features in hu being award of the contract was to have it the whole solution within a single product. So even though it was redundant, there was two of everything. It was still all in one single to U frame. And that was definitely the feedback we had from PBS was that was, is a major, uh, decision point in us getting the contract.
Simon:
The Tod technologies has been around it for quite a while. I can’t believe this is the first custom project you’ve done. Tell us about some other work you you’ve been involved in.
Steve:
Sure. There’s a couple others, uh, which come to mind, uh, there’s three angels broadcasting, which is religious broadcaster here in the states and they were doing a satellite distribution that we had our equipment, each site receiving over the, or the satellite feed. But one thing they needed to do for government compliance was to be able to insert alert messages, and they didn’t wanna go through the expense and the quality, uh, uh, degradation by decoding and recoding it site to put the alert message in. So we came up with a method to basically take the alert message, uh, replace all the programs in the stream with the alert message for the duration. Then it’s done switch everything back. So that way they can be compliant without having to decode and reco re-encode at each location. Another custom project we did was in Mexico, uh, a system and we had called D2propel where they were also doing a site like distribution.
Steve:
And in this case at each site, they did knew that did need to do a decode and recode cause they’re inserting local content at each location. But the one issue they had though is they needed program guide information and it was the same program guide information, every location. But since they’re doing a decode Recode, if they did the, uh, program guide generation at the uplink, it would all be lost. And they, so they’re looking at the expense of having to put in a generation, uh, at each location, which would be very expensive and very redundant, cuz it’d all be the same guide information. So what we did with our system, which is already deployed at each site was we took the satellite feed in with the guide information. We take the guide information out, send it out our first output to be decoded recoded for local content. Then we take it back in our second input, put the guide information back in and send it out our second output to go into transmitter for broadcast. So that way they can only have one, uh, guide generation at the uplink and not have to have that added expense of having one at every, uh, location.
Matt:
Yeah, I think I partly was to also see whether you’ve learn anything over the years of doing all of these, uh, custom projects. They must, you must have identified some, some sort of some vital, some key elements that you and both you and the customer need to achieve. Sure. When you are entering into a custom project like this,
Steve:
Correct? Yeah, yeah. Here at D2D, we love doing custom projects. It’s, it’s very challenging. We really like that working one on one with the customer and also being a small, nimble company. It it’s nice that, uh, you know, basically with the PBS project, it’s pretty much involved in, in every, uh, phone call and meeting. So if something needs to be changed, it doesn’t have to go up through four levels of management to somebody who’s not even involved in the project to make a decision. You know, I can make the decision right there so we can be very flexible. But some of the other keys, uh, we learned, uh, was that, well, it’s important to have a, a very detailed and comprehensive statement of, of work that you should build in flexibility, cuz there’s always things that you didn’t think of or, you know, you thought would work one way, but once you actually implemented it doesn’t quite work the way you thought. So you want some flexibility built-in. You also wanna be able to break that statement of work down to smaller tasks, which would be easily manage and track. We wanna very iterate. We work closely with the, the customer. So ensure the project stays on the schedule and it’s meeting what they’re actually looking for. It’s also good that before you actually do full deployment, you wanna do some beta testing, some real world environments. Then finally just the ongoing support, uh, and enhancements based on customer feedback.
Simon:
Yeah. That’s so some good, good, good advice, sir. Steve, thank you very much indeed. For your time today, today, it’s been great talking to you. Um, you’re welcome learning about and learning about your solutions and also the open gear solutions as well. And on the point of open gear, you can check out a channel for the other other openGear partners that we’ve been chatting to over the last couple of months. Do, um, also go to D2Dtechnologies.com, where you can find everything that, uh, Steve’s been talking about. And also there’s a full-length case study on there as well. Thanks to media proxy for their support care plus TV. And thank you for watching. We’ll see you next time.
