Open.HD, a video telemetry system utilising wifi hardware

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

plugger

Well-Known Member
Joined
Apr 30, 2009
Messages
759
Reaction score
454
So I saw this earlier in the week and I must say I'm pretty impressed. Basically they're taking wifi cards but modding them in software to transmit more akin to a standard/dummy radio (that's my ignorant understanding, I've not dug into it that much). They are then used for long range FPV/telemetry purposes.

Here's the github project page

And here's a demo showing it working out to 20km!

 
Very cool if true (20km), I am skeptical based on tried and true link budget considerations. I have not read much on the site but are they using and power amplifiers on the WiFi RF?
 
Their recommended WiFi adapter on the "air side" is an Alfa036mha, which is a 2W 802.11b/g/n USB device. Not sure if that's FCC-legal... I was under the impression that 1W is the limit, so it probably would require a Ham license. The software runs on a Raspberry Pi, so these two are going to take a lot of room and a lot of power. For a decently sized HPR rocket, it may work, but it's definitely a "project" payload.
 
Their recommended WiFi adapter on the "air side" is an Alfa036mha, which is a 2W 802.11b/g/n USB device. Not sure if that's FCC-legal... I was under the impression that 1W is the limit, so it probably would require a Ham license..

Is that even possible? Wouldn’t the Ham call sign still have to be transmitted periodically in CW? Or can it just be included in the WiFi SSID or something like that?
 
Good point... it would be pretty easy to do, though. I just reread the 15.247 regs, you're allowed 30 dB (1W) + 6 dB for the antenna gain... effectively 36 dB total link budget on the transmitting side, however the power fed to the antenna can't exceed 1W.
 
Their recommended WiFi adapter on the "air side" is an Alfa036mha, which is a 2W 802.11b/g/n USB device. Not sure if that's FCC-legal... I was under the impression that 1W is the limit, so it probably would require a Ham license. The software runs on a Raspberry Pi, so these two are going to take a lot of room and a lot of power. For a decently sized HPR rocket, it may work, but it's definitely a "project" payload.

Good question on the FCC side. I can't speak authoritatively on that but I'm not beholden to them anyway (down here it's ACMA). What I can say is that I run an Alfa AWUS036NH (the other Alfa 2W 2.4GHz radio) as the backhaul radio for my wifi link to my shed and that unit has the FCC and CE logos on it. See below.

As for the Raspberry Pi comment, the 'air' side utilises a Raspberry Pi Zero board. That unit is 2.6 x 1.2 x 0.2 inches, which is smaller than your Proton unit in terms of dimensions. And if I'm not mistaken all that's required to power the unit is a 2S Lipo hanging off a 5V BEC.
 

Attachments

  • alfa-2W.png
    alfa-2W.png
    271.3 KB · Views: 22
Is that even possible? Wouldn’t the Ham call sign still have to be transmitted periodically in CW? Or can it just be included in the WiFi SSID or something like that?
AFAIK, it is not required to be identified via CW, just that it be identified every 10 minutes and at close of transmission.
 
AFAIK, it is not required to be identified via CW, just that it be identified every 10 minutes and at close of transmission.
I’m still puzzled how to send the identification. Are you saying it is not necessary to send the call sign in Morse code? Is there some other acceptable method to send the call sign In this situation?
 
I’m still puzzled how to send the identification. Are you saying it is not necessary to send the call sign in Morse code? Is there some other acceptable method to send the call sign In this situation?
Yes. You can send it in the data stream, as an image, or any legal transmission mode for the frequency you're using. Personally, I wouldn't mix any mode other than Morse/CW with any other mode, so no ATV and RTTY, but as long as you're not encrypting your datasteam, send it as part of data.

The reason you hear a lot of repeaters using CW for ID is as a courtesy for those using the repeater. CW is quick and relatively non-intrusive for an every 10 minute ID during QSOs on the repeater. A voice ID might talk over someone trying to hold a conversation.

NOTE: It is always legal to ID using Morse code, if you choose to do so.

See: https://www.law.cornell.edu/cfr/text/47/97.119 for more information. Note that it implies non-RTTY data as part of the RTTY section.
 
Anyone know if this is intended for quadcopters/drones or for rocketry?

I was under the impression that the quadcopter/drone transmission systems were highly optimized for horizontal transmission, not vertical transmission (vertical transmission is what would be needed for rocketry).
 
Yes. You can send it in the data stream ... <snip> ... as long as you're not encrypting your data steam, send it as part of data.
See: https://www.law.cornell.edu/cfr/text/47/97.119 for more information. Note that it implies non-RTTY data as part of the RTTY section.

I must be missing something. I would love to just embed the station ID into the data stream but I don't see where the regulations say that is allowed. In the regulations you cited, section 97.119 (b) (3) says: the station ID must be transmitted "by a RTTY emission using a specified digital code when all or part of the communications are transmitted by a RTTY or data emission". I assume the WiFi signal being discussed here would be considered a "data emission". My understanding is RTTY is a narrow-band direct-printing telegraphy emission. Sending the station ID that way would be separate from the data stream itself. What am I missing?
 
I must be missing something. I would love to just embed the station ID into the data stream but I don't see where the regulations say that is allowed. In the regulations you cited, section 97.119 (b) (3) says: the station ID must be transmitted "by a RTTY emission using a specified digital code when all or part of the communications are transmitted by a RTTY or data emission". I assume the WiFi signal being discussed here would be considered a "data emission". My understanding is RTTY is a narrow-band direct-printing telegraphy emission. Sending the station ID that way would be separate from the data stream itself. What am I missing?
Your WiFi signal is a "data emission" as you stated. Therefore, you would sending the station ID in the data stream.
 
Your WiFi signal is a "data emission" as you stated. Therefore, you would sending the station ID in the data stream.

Sorry, I still don't see where it says you can put the station ID into the data stream. My read of it says the station ID must be an RTTY emission if the communication is a data stream. Which makes sense to me since I don't see how anyone receiving the message could possibly hope to find the station ID embedded somewhere into a 10 minute burst of binary data. Even when the binary data stream is not encrypted.

By the way, I am not trying to argue a point for the sake arguing. I have an application of this in mind if the ID can really be included in a data stream. However, if it has to be sent by RTTY at the same frequency the data stream was transmitted at, then it all becomes a real pain to implement.
 
Sorry, I still don't see where it says you can put the station ID into the data stream. My read of it says the station ID must be an RTTY emission if the communication is a data stream. Which makes sense to me since I don't see how anyone receiving the message could possibly hope to find the station ID embedded somewhere into a 10 minute burst of binary data. Even when the binary data stream is not encrypted.

By the way, I am not trying to argue a point for the sake arguing. I have an application of this in mind if the ID can really be included in a data stream. However, if it has to be sent by RTTY at the same frequency the data stream was transmitted at, then it all becomes a real pain to implement.
If it's unclear, then I would check with the FCC. My understanding is that "specified digital code" is considered legitimate.
 
Here's a thought: APRS uses the datastream, not RTTY or Morse, to identify.

I had the same understanding as you. I thought that the essential requirement was that it was not encrypted. However the digital data is encoded is fine for the ID as well, including PSK31, RTTY, FT8, Hellschrieber, D-star, whatever.
 
Here's a thought: APRS uses the datastream, not RTTY or Morse, to identify.
That is a good point but I always assumed there is an established standard format for APRS packets and everyone knows where the station ID is sent within those packets. The conversation here started with WiFi and the question was whether a Ham could boost the WiFi signal power and transmit it longer distances so long as the Ham’s call sign was included in the data stream. It didn’t seem like that would be legal to me since it would be next to impossible for others to find the station ID.

Rather than WiFi, what I am really more interested in, is if it would be legal for a Ham to use one of the low power, short range IEEE 802.15.4 type data transceivers (such as a Zigbee device) to send data long ranges by boosting the transmit power and simply including the Ham’s call sign somewhere in the data stream.
 
That is a good point but I always assumed there is an established standard format for APRS packets and everyone knows where the station ID is sent within those packets. The conversation here started with WiFi and the question was whether a Ham could boost the WiFi signal power and transmit it longer distances so long as the Ham’s call sign was included in the data stream. It didn’t seem like that would be legal to me since it would be next to impossible for others to find the station ID.

Rather than WiFi, what I am really more interested in, is if it would be legal for a Ham to use one of the low power, short range IEEE 802.15.4 type data transceivers (such as a Zigbee device) to send data long ranges by boosting the transmit power and simply including the Ham’s call sign somewhere in the data stream.

Yes, see Mesh Networks:

http://oemcomm.org/ham-mesh-network-primer/
(I think that is what you're describing)
 
That is a good point but I always assumed there is an established standard format for APRS packets and everyone knows where the station ID is sent within those packets. The conversation here started with WiFi and the question was whether a Ham could boost the WiFi signal power and transmit it longer distances so long as the Ham’s call sign was included in the data stream. It didn’t seem like that would be legal to me since it would be next to impossible for others to find the station ID.

Rather than WiFi, what I am really more interested in, is if it would be legal for a Ham to use one of the low power, short range IEEE 802.15.4 type data transceivers (such as a Zigbee device) to send data long ranges by boosting the transmit power and simply including the Ham’s call sign somewhere in the data stream.

Shoot Vern, it should be legal as long as the frequency used is open for Ham Radio and one has a callsign. https://qrznow.com/ham-radio-frequency-chart/

Yeah in the setup for an APRS rig one generally has to input a legitimate callsign. I remember about 10 years ago some guy was running around the Peoria Illinois area with an APRS tracker in his car "just for fun". Had obvious "gibberish" for a callsign. There was a digipeater 400 yards from my house so I got to watch the fun on my laptop (Xastir) as two Hams tracked the guy down in a parking lot.

Said "somebody" gave him the radio and said it was "cool". The guy wasn't licensed and told him to turn it off until he got a Tech license at least and a legitimate callsign or the FCC would get ticked off if someone turns him in and he continues to violate the airwaves.

Kurt (a.k.a. KC9LDH)
(Gotta get that Extra class one of these days!)
 
The main gist is: Don't overthink. If you're putting it anywhere in the datastream where it's readable without decrypting it (NONE of your transmission should be encrypted if you're not talking to a satellite.), then you're good.
 
NONE of your transmission should be encrypted if you're not talking to a satellite.
And here I thought encrypted transmissions were completely unavailable to the amateur radio community. When I did my class down here that was one of the take aways I was disappointed about as I was told legally you couldn't encrypt transmissions for anything.
 
Let me try to make this clear. APRS and NMEA GPS trackers are not encrypted. They are digital data streams that anyone with the proper receiver can see the strings. There is no secret "key" that one has to use to decode the position data.

I've streamed EggFinder position data to a laptop tracking program and see the plain english data coming in nicely which is in the form of the NMEA strings as is sent from the GPS chipset to outside peripherals. In a mapping GPS, the positions are sent to the screen/map. With a tracker, they go out over Rf to a receiver. Any receiver that can process the data will work. This is NOT encryption and is perfectly legal for anyone. It's a protocol. Anyone who's using a no license required tracker or a Ham with a callsign using the Ham frequencies. No problem.

I was trying to come up with an essentially, cheap, "disposable" GPS tracker in the Ham bands.
Disposable in that if the rocket core sampled or was lost, one wouldn't be out a pile of money. It was around $25.00 for parts cost. I used 3Dr radios.

Now the snag I hit with my experimenting was getting my call sign into the data stream. Most "full-featured" GPS chipsets allow one to connect the GPS to a computer and one can add a call sign in a comment section in the NMEA stream. It will be seen in plain english in a position string so is perfectly legal for a Ham to use. My problem was I was using cheaper versions of accepted GPS chipsets and guess what?
The chip makers inactivated portions of the programming software that would have allowed me to put my callsign in! I tried 3 kinds of GPS chipsets and discovered the same thing. I then found out about the "pricier" versions of the same GPS had all the programming features unlocked but they were $125.00 or more!! That nixed that experiment as spending that much for just the GPS chip defeated the purpose of it being "disposable".

APRS can only reliably send out position packets once every 5 seconds. I got it down to 3 seconds for testing using Xastir on a laptop wired to a Ham radio. 3 seconds was doable but the kicker there was packet collisions and a usable signal couldn't be transmitted any less than once every 3 seconds. No commercial APRS GPS tracker can be dialed less than once every 5 seconds. Five seconds is fine to use to locate rockets using APRS.

I was experimenting with 3Dr radios in the prior paragraph in the 900Mhz and 433Mhz bands transmitting the NMEA strings like the EggFinder. As said on 433Mhz I couldn't get the callsign in the stream so that was out. On the no license required 900Mhz band as long as I followed the
power limitations I was legal. Interesting thing here is I used a GPS chipset that utilized both the U.S. and Russian Glonass system with resultant better accuracy. Pretty impressive but more like accuracy to the point of absurdity. Nice to have but using the U.S. system alone is good enough to find a rocket.

Eggfinder has a mini GPS tracker and receiver in the 70cm Ham band I haven't had a chance to build mine yet and see the NMEA strings coming over the receiver. Might be better propagation over 900 Mhz.

Kurt Savegnago KC9LDH
 
And here I thought encrypted transmissions were completely unavailable to the amateur radio community. When I did my class down here that was one of the take aways I was disappointed about as I was told legally you couldn't encrypt transmissions for anything.
Specifically, §97.211 (https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.97) allows for a space telecommand station to use encryption to obscure the meaning of telecommand messages to the station in space operation. This is intended to keep an unauthorized person from illicitly gaining control of an amateur satellite. There are a few other exceptions to the "no encryption" rule, but that's the main one.
 
Specifically, §97.211 (https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.97) allows for a space telecommand station to use encryption to obscure the meaning of telecommand messages to the station in space operation. This is intended to keep an unauthorized person from illicitly gaining control of an amateur satellite. There are a few other exceptions to the "no encryption" rule, but that's the main one.

Agreed John. I wanted to point out that APRS and NMEA are protocols that any Ham can use for tracking and are not considered encryption. Kurt
 
Specifically, §97.211 (https://www.ecfr.gov/cgi-bin/text-idx?node=pt47.5.97) allows for a space telecommand station to use encryption to obscure the meaning of telecommand messages to the station in space operation. This is intended to keep an unauthorized person from illicitly gaining control of an amateur satellite. There are a few other exceptions to the "no encryption" rule, but that's the main one.
Thanks for the response and link John. I appreciate it.
 
So I saw this earlier in the week and I must say I'm pretty impressed. Basically they're taking wifi cards but modding them in software to transmit more akin to a standard/dummy radio (that's my ignorant understanding, I've not dug into it that much). They are then used for long range FPV/telemetry purposes.

Here's the github project page

And here's a demo showing it working out to 20km!


I've been active in the Open HD community, working on tweaking my own setup. Could have applications for rocketry. one guy recently hit 50km

https://forum.openhdfpv.org/t/50k-on-asus-ac-56-5260mhz/525
 
Back
Top