Bob's Adventures in Wireless and Video Headline Animator

Thursday, October 28, 2010

Poor Man's ENG

ENG, Electronic News Gathering, Remote Broadcasting, Live to it what you will, it all means the same thing...Get video from a camera at a remote site back to a network so that it can be broadcast live.

Most TV broadcasters use COFDM licensed systems for their ENG. This technology, while highly reliable, generally has a short range between the camera and a truck, and a high price. If you are billing at $1 million a minute for Superbowl ads, this solution makes a lot of sense. But if you are a dad trying to broadcast the local high school football game over the Internet with a very limited budget, then you are out of luck.

Sounds easy, right? Well it is not as easy as it sounds. For over 5 years we have been working on a way to do this using low cost unlicensed wireless IP systems. HauteSpot has built video encoders that are integrated with wireless transmitters starting with our first HauteSHOT system that used MPEG-2 and 802.11 which were low resolution, jittery, and did not offer great range and continuing with our most recent systems. We have learned a lot and improved a lot.

With the advent of our new H.264 HD encoders, which support HD-SDI or HDMI input from consumer grade to professional quality cameras, we can compress video down to a stream that is small enough to squeeze through even 3G wireless links yet retain their quality. Combine this with the jitter free performance of our second generation TDMA Like Protocol (TLP), we can deliver long range, low cost, high quality video streaming from almost any location.

We are now working on combining the solutions into one compact size platform that can be camera back mounted. The end result is a system that will deliver near professional quality live to air video broadcasting at a fraction of the cost of COFDM.

So my question to you is: "What new applications for live to air video production will a low cost system like this enable?" and "Where is the best place to focus our marketing efforts for a product like this?"

Give us your feedback.

Sunday, October 17, 2010

Exercise Capital Shield

Last week I was invited to participate in Exercise Capital Shield 2011 (Cap Shield), an interagency emergency management exercise conducted in the Washington DC area. The exercise brought together over 80 local, state and federal healthcare providers and emergency response agencies from throughout the National Capital Region (NCR). Cap Shield simulated large-scale disasters across multiple sites and involved the coordination of multiple jurisdictions. From patient extraction and triage at remote sites, through transportation and ultimate delivery to destination hospitals, the exercise tested the readiness for real, large scale disaster response. 

To assist in the management of the exercise, the National Capital Region Medical-Joint Task Force (JTF-CapMed) in conjunction with Walter Reed Army Medical Center and other hospitals within the area enlisted the help of Global Emergency Resources, LLC. (GER) to provide end-to-end patient tracking and situational awareness to all participants. To achieve the exercise mission, GER provided their industry leading HC Standard® patient tracking software and a complete wireless communications infrastructure. The GER solution delivered real time patient tracking data and live video between remote sites, and along the entire route, to the hospitals.
HC Standard® Mobile Patient Tracking runs on a simple to use hand held, ruggedized Motorola MC75 personal computer. First Responders in the field follow intuitive graphical prompts and use integrated bar code scanners to speed through tasks such as recording patient data, updating patient details and providing real time transportation status. Video is also captured using wireless cameras on the scene. The data and video are transmitted wirelessly using either secure cellular or wireless protocols and over highly redundant communications networks using GER’s Emergency Wireless Routing Access Point™ (EWRAP™) routers developed specifically for this purpose for GER by HauteSpot Networks.

Hospitals and Emergency Operations Centers can easily view and report on patient data in real time using intuitive, highly flexible browser based tools which can run on virtually any computer to access up to the minute patient statistics including color images, audio, and video from the incident scene. All data is provided to health care and emergency management personnel in order to allow for rapid assessment of the incident and proper allocation of critical resources. This information is stored and can be reviewed for after action reporting at any time in the future.

What was really cool was how easily everything ran. In less than 10 minutes we had every EWRAP set up with full mesh coverage and streaming video running. Even in the pouring rain, our system worked great. We did have to put plastic bags over the cameras we used, as they were not outdoor rated.
There were only two hiccups that we had during the two days of exercises:

The first was that we forgot to open the vent on the gas tank on a generator and the system stopped shortly after start up. Lesson learned...check everything three times.

The second was one EWRAP that kept having video drop due to bandwidth issues. This issue was weird, since we could see no obvious issues and we spent some time trying to figure out what was going on. What we found out was that apparently one of the military communication truck that was near by was using our open 802.11 connection to download video of the exercise because their satellite connection was too slow. We were surprised and pleased to see that a low cost EWRAP provided better communications than a very expensive comm truck on the same remote site.
We are really excited about the results of this event and expect upcoming events to go even better.

Sunday, October 3, 2010

Video Streaming From Dynamic Networks

We have built a new router that is designed for emergency first responders. The router creates a mesh between other routers, and then backhauls via cellular, public safety, 802.11 or 802.16.

We have added in a number of features to maintain default gateways, manage connections, determine link quality, etc. The router is designed to require no user interaction and be fully self configuring.

We use dynamic dns to allow for remote inbound connections.

Everything works great for outbound connections from devices connected to the mesh. It is completely dynamic and works very reliably, when data connections are initiated from the local side of the network.

Our client wants to connect IP cameras for live video streaming. This is where things get interesting. We expected that we could simply set up an IP camera to use announced unicast to push video to a server. But after extensive searching we have concluded that there is no IP camera on the market that can do this. I know it is hard to believe, but it appears to be true. Every single manufacturer expects you to have a server local to the camera and pull the video to the server.

So we have to put a server local to the cameras on the mesh and then connect from the local server back to another server for broadcast. Bringing a server on scene is good in one respect that it puts a more reliable recording method closer to the video source. But not all customers want to carry around a server. Some just want to get situational awareness through video streaming back and only have minimal equipment on scene.

So we are now investigating making our own camera that is specifically designed for this type of application. When we are done we will have a great, lightweight, easy to use camera that can push video to a remote server via HauteSpot wireless routers.

Any suggestions or other ideas?

Monday, September 6, 2010

Everyone is Jumping on the TDMA bandwagon

TDMA, or Time Division Multiple Access, has been used by HauteSpot Networks to carry video and voice streaming over broadband wireless for over 5 years. It is only in the last few months that we have seen a number of vendors copying our lead and innovation in the market by offering TDMA in their products.

Why does TDMA matter? Early on wireless engineers in the voice business investigated technologies which would reduce jitter in voice streams. Jitter is another way of saying delay variation.

When video or voice is packetized (where the analog stream is converted to digital bits, and then the bits are grouped into packets for transmission on an addressed network) the packets are sent out in a specific order with very specific timing or spacing between the packets. This allows the receiver to decode the received data and play it back using the same timing as when it was sent. If the packets move across the network in an orderly process at the same speed, then they arrive in order and with even spacing and the receiver can play them back as if there was no network in between.

However, in the real world networks are variable. There are many factors that can contribute to delay variation such as collisions, congestion, route variation, forwarding delay by routers or bridges, encoding latency and decoding latency. There are really only a few things you can do to reduce jitter. You can either ignore lost data and fill in the blanks, or you can buffer received data as it comes in. When you have received enough data to smooth out variations in delay, then you can play out from the buffer. We call this jitter buffering.

In the case of dropping data, the issues are obvious. You may have no video or voice, poor quality video or voice, or lots of starts and stops depending on how bad the loss is. In the case of jitter buffering you may see delays ranging from a few milliseconds to minutes. We have all experienced the count down clock on You Tube. This is the jitter buffer at work.

Wi-Fi uses a protocol referred to as CSMA/CA or Carrier Sense Multiple Access/Collision Avoidance. Basically every Wi-Fi device will first listen to the air to see if there is any traffic, then it will send. If two Wi-Fi devices send at the same time, there is a collision. If they detect a collision, then they have to back off a random time period and resend. This scheme works well in short range where the network is heterogeneous. Meaning that the data on the network is bursty and timing is not so important. With voice and video this is not the case. Video and voice cannot wait for retransmission.

TDMA on the other hand is a controlled network where a master unit provides time slot control to all the members of the network. It eliminates collisions by making sure that no two members of the network send at the same time. It also makes sure that the time between slots for each member of the network are evenly spaced. TDMA provides the transport environment that video and voice need to flow smoothly.

HauteSpot Networks realized the issues with retransmission long ago and implemented a variation of TDMA that co-existed with Wi-Fi on unlicensed channels. Our first implementation, the HauteLine protocol, was limited to point to point links. Later we developed the TLP or TDMA Like Protocol, which supported point to multipoint. TLP has been in development and used in HauteSpot routers for the last 4 years. Our competitors only recently figured this out.

But, it is not enough to just implement TDMA. Using unlicensed frequencies means that you need to co-exist with Wi-Fi. Wi-Fi devices will not pay attention to your TDMA network timing. They will still send, even when your network master has not authorized them to do so. So collisions are still possible. Most of our competitors will revert to using collision detection and retransmission using the same methods as Wi-Fi. They will use acknowledgment (ACK) and non-acknowledgment (NAK) frames to indicate if data was received or not. They will wait for acknowledgment before moving on. This will introduce delay variation. So in a crowded environment they will have performance approaching that of Wi-Fi.

Through our years of experience we have learned that there are many other methods of detecting collisions which are much less disruptive to data flow. HauteSpot's TLP protocol uses a sliding window method of retransmission which creates much less jitter. It also eliminates ACK and NAK frames, significantly reducing network overhead and improving efficiency. It also allows HauteSpot to co-exist with Wi-Fi in heavily congested areas and still perform and scale well.

We suppose imitation is the highest form of flattery. But only good imitation really matters. Test your network performance, especially jitter, and you will see what a difference good design makes. It takes time to refine design and prove under real world conditions what works best. Those who are just learning now how to make video and voice work well over wireless broadband have a long way to go.

If you want to learn more about TLP, just ask. We may need to get you under NDA, but we will answer your questions.

Saturday, August 28, 2010

IP Video Transport Protocols

There was a post on LinkedIn regarding why the transport protocol between the the VMS software (NVR) and an IP Camera matters. I thought I would share my response.

Camera and VMS manufacturers are big on promoting their video compression algorithms such as Motion JPEG, MPEG4, or H.264. But try to pry out of them what transport protocols they use to communicate and it is a completely different story.

The need to know transport protocols supported (HTTP, Unicast, Multicast, RTSP/RTP over TCP, RTSP/RTP over UDP, TFTP/proprietary) is essential for determining performance over wireless and wide area network links.

For instance, if the VMS and the camera are remote from each other over a routed network (aka Internet) protocols like TFTP simply will not work at all. HTTP may work, but it will depend on how much buffer the camera has and how much jitter buffer the VMS will have, and how important latency is to your application.

Then we get to RTSP/RTP. ONVIF decided to implement RTSP/RTP over TCP as the preferred transport protocol because it is efficient and easy (lets the application off the hook for verifying guaranteed delivery). ONVIF used TCP because they wanted to enforce guaranteed packet delivery for chain of evidence and intrusion detection. But TCP forces packet level acknowledgment which is sub optimal on limited bandwidth networks. IPTV has been using RTP/RTP over UDP for years because it is more efficient and runs well over networks that are not deterministic (aka Internet). But UDP does force the application (aka VMS) to verify data delivery. We really wish that ONVIF had specified the use of UDP as the preferred method so that surveillance could scale over the Internet. UDP is an optional method in ONVIF, but we know of only one VMS system that supports it.

Anyway, for the last two years we have been testing cameras and VMS systems over our wireless links and carefully watching their transport protocol behavior and efficiency. We keep a list of the best and the worst VMS/camera combinations and have developed work around solutions (full duplex wireless for example) for transport protocols that are sub-optimal. Typically these sub-optimal protocols are very latency

Since our wireless protocol is optimized for video (TDMA derivative) we only say how these combinations work with our gear and not over 802.11, mesh, EV-DO, or other networks.

Our preference list for transport is:
RTSP/RTP over UDP (IPTV spec)
RTSP/RTP over TCP (ONVIF spec)
TFTP (these are always proprietary implementations, not actual TFTP) 

We have found that getting information on what transport the VMS has implemented with a particular camera is impossible. Many of the VMS tech support folks don't even know. We have even been told by some VMS mfgs that they are using RTSP/RTP but when we sniff it, they are actually using HTTP.

We are hoping that an independent third party would provide a definitive list of who is using what as it would help people out immensely. One place to start is which at least tells you which cameras support RTSP, but not how they have implemented it or which VMS are supporting same.

Let me know if you have other ideas about how to solve this.

Saturday, August 21, 2010

Greetings and Solicitations

What I am going to try to do here is chronicle my daily experiences in designing, building, installing and trouble shooting wireless and video applications. We may wander through the world of video, RF, construction, mobile, lighting, police, perimeter security, fire fighting, DOD, EMS and who knows what else.

For those of you who don't know me, I am engaged in two different companies at present: HauteSpot Networks, who makes wireless routers for video and voice streaming; and MicroPower Technologies who makes ultra power efficient wireless cameras (really small and really wireless -- no power cord).

HauteSpot has been something that I have been working at for almost 5 years now. We started by trying to sell high performance wireless IP routers to the TV broadcast market. We built low cost routers (relative to COFDM solutions that were available at the time). Unfortunately we were about 4 years ahead of the market. Broadcasters really didn't need the performance that we offered.

About 2 years ago, the video surveillance market started to really adopt IP cameras and we shifted our focus to this market. The early offerings in IP surveillance were bandwidth hogs and used transport protocols that were impossible for standard wireless technologies such as WiFi to handle well. Having a lot of experience in moving video without jitter (delay variation that makes video unreliable and full of artifacts), we were able to deliver great performance for video over wireless when our competitors fell down.

Now we are seeing broad adoption of our wireless routers in the public safety, commercial security, homeland security and more. So the market is finally catching up with us.

One gap that we identified was battery/solar powered and wearable operations. Particularly in building wireless solar powered cameras there really were no good options. Our routers, while delivering excellent performance, were not designed for low power. So solar panels are large, batteries are large, construction costs are get the idea.

This led me to MicroPower, who has an excellent technology for running wireless IP cameras at very little power. I associated myself with MicroPower in a business development role and started using my years of experience in the surveillance market to build up MicroPower's position.

So now I am immersed at the center of the storm of wireless and video, with contemporary technologies (some might say bleeding edge). I would like to think that I have become a trusted source for technical information to my customers.

So now that you know me, I will move forward with my world of learning...Call me out if I am wrong, pat me on the back if I help you.