Wireless temperature data logger in the USA on 433MHz

I'm a newly licensed ham tech. I am trying to figure out if I am doing everything correctly to setup a wireless temperature monitoring station that uses the 70cm band (specifically 433.4MHz) in the USA.

This setup will involve a station that is positioned on a lake about 300-400 feet from a receiving station in my house. The station located on the lake will transmit water temperature data once per hour with transmission durations of 1 second or less (more likely milliseconds). The receiving station will receive this data and upload it to the internet. This is for environmental non-commercial purposes. The data will not be encrypted but will be in some form of a binary protocol.

I'm planning to tune the transceivers to use the least amount of power required for successful communication. I read somewhere that I should include my callsign on the outside of the device that is transmitting as well as in the actual data being transmitted.

The station on the water will be in a locked box preventing anyone from manually interfering with the equipment.

I have some SDR equipment that I have been using to listen on 433.4MHz to make sure that I'm not going to interfere with anything.

Do I have any bad assumptions or am I overlooking anything? Some feedback would be really appreciated. I haven't had much luck finding resources that spell this stuff out. I have looked at some references for APRS, but all that I have found seems pretty specific -- it seems like what I want to do is in the same spirit of APRS, but may use a different protocol etc.

Any links to solid references would be appreciated as well.

Update: I currently have some 433MHz transceivers that are very affordable, extremely easy to interface with (serial), and can be operated at both 5v and 3.3v: elecrow.com/download/HC-12.pdf My weather station is going to be powered by arduino and my receiving station will be powered by a raspberry pi. Now that I am a licensed ham, can I use these transceivers in the US?

• So, is the question you want to have answered "can I operate this specific module as US ham?"? Because then, you should probably highlight that. – Marcus Müller Mar 10 '18 at 16:18
• (also, why buy a device certified to work in European ISM bands and then use it in American ham bands? Could've gone for the american ISM band variant and skipped the whole "am I allowed to operate this" question.) – Marcus Müller Mar 10 '18 at 16:21
• Yeah sorry. I was trying to highlight the aspect of automatic control since using this device in the US falls under amateur radio instead of ISM. I bought these transceivers and designed much of my project before I knew anything. Then when I realized 433MHz was a ham frequency I went the route of getting licensed. Now I'm thinking I just doubled down on being stupid. I could switch to 900MHz for additional cost and time. If everyone thought I would be totally fine with my 433MHz setup I would probably stick with it. – kr4sh Mar 10 '18 at 16:44

Legal discussion

To ISM or not to ISM, that is the question

So, in Europe, 433 MHz is an ISM band – you could even operate a device there if you weren't a licensed Ham! That also includes the fact that if you choose to go for unlicensed operation rather than amateur licensed operation, the no-encryption rule, and the callsign rule (both of which frankly don't make overly much sense in this day and age, in my humble opinion) don't apply to your use case. Now, in the US, it's not an ISM band, but if I read your question correctly, it wouldn't hurt you if you had to switch to the 900 MHz ISM band. (whether you do that or not doesn't really matter for the technical discussion below)

ISM band situation

Now, that's about how much legal advice about the situation in the USA I can give; I'm not a lawyer, and a European on top of that. Generally, even ISM-band devices must adhere to regulations. It really depends on the legislation, but for example, in Europe, there's what we call "Short Range Devices", and the rules these must fulfill are rather lax – depending on the band, low duty cycle, low transmit power and negligible out-of-band emissions ensured by "appropriate" engineering. Nothing about spending a few grand on lab testing and certification as necessary for other operational classes.

Technical discussion

Tickling you with a bit of background

Now, your weather station needs pretty much next to no data rate at all – you can happily spread out energy as much in time and/or frequency as you want to, given you then "collect" it at the receiver again. That's what for example GPS does – the satellites' signals at the receiver are usually all below thermal noise floor, but due to integrating over enough time, your GPS still works reliably.

We typically call these technologies spread spectrum. There's quite a few different implementations. For example, if you want to work with readily engineered long-range modules that you can just wire up to a microcontroller and easily talk to, LoRa is a manufacturer-proprietary technology for machine-to-machine communication (M2M, exactly what you're doing!) in ISM bands. It should work reliably over the comparatively short distance you're trying to cover, even if it uses higher frequencies. It uses what they call Chirp Spread-Spectrum, which is an interesting thing to do, though not inherently extremely intuitive from a theoretical point of view.

If you instead want to build this yourself, you could very easily build your own spread-spectrum transmitter. It's not hard at all – in fact, if you have a transmitter that uses a linear modulation, and can feed it with any data stream you want, it's pretty easy. Think about Direct-Sequence Spread Spectrum, DSSS: Typically, you just go and multiply a symbol by a symbol sequence and transmit that. Imagine, you want to transmit the bits 110011. Now, you say that a 0-bit is -1, and 1-bit is +1. Instead of just transmitting +1 +1 -1 -1 +1 +1, you pick a sequence, let's say +1 +1 -1 -1 as spreading code.

Then, you take each of your transmit symbols, and multiply it by the sequence (so you replace +1 by +1 +1 -1 -1 and -1 by -1 -1 +1 +1), and just transmit the result (after concatenating what you've got):

+1 +1 -1 -1 +1 +1 -1 -1 -1 -1 +1 +1 -1 -1 +1 +1 +1 +1 -1 -1 +1 +1 -1 -1

At the receiver, you just correlate with the same spreading sequence. That basically means you're taking the received signal, four values of that, and multiply it point-by-point with +1 +1 -1 -1, then sum up the four values you've gotten, and get an amplitude. Then, you shift your input signal by one, and do the same. Whenever you get nice and high values, you've "hit" a transmit signal (instead of just noise).

There's a bit of a trick to picking these spreading sequences. You want them to have a well-shaped autocorrelation function, meaning that when you multiply them with themselves, shifted by any amount of time but 0, they will have low values, but high values when multiplied-summed without any time offset. That way, you can actually successfully synchronize your receiver to your transmitter and eliminate as much of the channel influence as possible.

From this requirement comes that you get better performance for longer sequences (that's kinda logical – the more values you add up, the higher your value gets if you're actually multiplying with the right sequence instead of noise), and that you'll pick sequences that aren't periodical in themselves – because if they were, they'd be similar to a shifted version of themselves, and thus would not fulfill the autocorrelation criteria. If in doubt, Gold codes are a good source of such sequences, and don't be shy about length – modern wide area network standards allow for sequences up in the dozens of thousands of symbols in length¹.

Thus, if you have a transmitter that can either send +1 or -1 (or QPSK, or anything that is a linear modulation, which pretty much is everything but plain FSK, really), then you can also make it send +sequence and -sequence just by replacing the raw data with the coded data. To let your receiver know that you're about to start sending data, you could also prepend your callsign to the weather station data, and encode that along with it. That would a) give you a preamble and b) fulfill the ham callsign requirement.

Buying dedicated RF transceiver chips / boards

You could implement that transmitter with a cheap microcontroler that integrates a radio frontend; for example, TI sells the CC1310, and an eval kit board costs 30$(also comes in a 433 MHz version. Haven't worked with that, but the chip does come with built-in support for spreading sequences, so that sounds nice for your application, and you could have one on both ends of your link, and probably TI will give you some example code to make them talk to each other. A quick word about why these devices exist Notice: exactly what you're building is something that is of large commercial interest, so it's no big surprise TI and other companies try to make it easy to use their products to implement what you want! Integrating that with a microcontroller makes a lot of sense – people that build devices like weather stations don't want to have yet another chip on their board that only does the RF, and then a microcontroller to control that RF chip, and then hope that they can avoid having yet another microcontroller just to control the weather sensing devices, they want one controller to at least do the job of the RF interface reliably, and they want someone who had the time to test all this to have implemented the radio control layer. Makes much more sense that way. A self-built receiver If you want to implement the receiver yourself, you'll need the correlator, and something to sync. You said you had an SDR – I simply postulate that as you're building something cool, another 10$ RTL dongle won't hurt you much, so you can just receive that signal, and do the above correlation (which, really, is just a FIR filter with the reversed sequence as taps) in software – for example, on a cheap small computer like the raspberry pi.

I'd go into detail here – but "how do I build a DSSS receiver with a Raspberry Pi, an RTL dongle and minimal effort, matching my transmitter" would be worth opening a new question, if this is the way to you choose to go, and I don't want to overburden you with details at this point. But really, other people have built SDR receivers (and transmitters) for such systems. For example, see this gr-lpwan presentation that, with less than 5 mW transmit power worked on 2.4 GHz (which has more than 10dB more path loss for the same distance than 433 MHz, if I'm not mistaken!), worked over a couple of kilometers, even in the shadow of large buildings; don't let yourself be scared by the math and complexity. This is a full implementation of a complex standard, not a "works for my weather station (and that's enough for now)" approach.

¹ Talking about IEEE802.15.4-LECIM in case anyone wonders.

• Wow great information. Thank you! I have already purchased some 433MHz transceivers that are very affordable, extremely easy to interface with (serial), and can be operated at both 5v and 3.3v: elecrow.com/download/HC-12.pdf My weather station is going to be powered by arduino and my receiving station will be powered by a raspberry pi. I'm still confused about the legality. Now that I am licensed, can I use these transceivers in the US? – kr4sh Mar 10 '18 at 15:38
• … that's definitely something you could've mentioned in your question! As I said in my answer, I'm not the right person to ask about legal stuff in the US. – Marcus Müller Mar 10 '18 at 16:03
• sorry :-( I updated the question. Thanks for the information. – kr4sh Mar 10 '18 at 16:09

In the US, if you don't want to reinvent the wheel then your easiest solution would probably be APRS, more specifically the Citizen Weather Observer Program, which is a standardized system to send weather station data to the National Oceanic and Atmospheric Administration via APRS and/or the internet. Thousands of weather stations in North America already participate.

On the weather station end, you would need:

• A power source, possibly solar.
• A weather station that sends its data through a serial connection in a format recognized by the software or the controller.
• A computer running software, or a "weather station controller", that receives the serial weather data and outputs APRS-formatted packets. See the CWOP page I linked to for a comprehensive list of software and hardware solutions; a Raspberry Pi could serve as an inexpensive computer that doesn't draw much power.

If the weather station is only 300 – 400 feet from the house, then the easiest way to do the wireless link might be Wi-Fi to a computer in the house, which could send the weather data via the internet. But if you want to use APRS, then you would also need:

• A hardware TNC such as the TinyTrak4, or a "software TNC", which is software that would output tones through a sound card that can be coupled directly to a radio
• A VHF and/or UHF radio tuned to the APRS frequency
• A suitable antenna

So far I have assumed that you live close enough to an existing digipeater that can conveniently receive the APRS packets and put them on the internet for you. If you can hear packets on 144.39 MHz, then you probably are in range of such a digipeater (or a digipeater that could relay packets to an internet-connected digipeater). You can also look at aprs.fi to see a map showing digipeaters and other packet stations near you.

If you are within reach of such a digipeater, then sending the weather data as packets over the North American packet frequency of 144.39 MHz would probably be your simplest solution. At the house, you could see the data moments later that had been relayed via the internet by the digipeater.

On the other hand, if there is no nearby digipeater, or if you are bound and determined to use the 70cm band (APRS on the 70cm band is much more uncommon, but can and has been done) then you could construct your own digipeater at the house to relay the packets to the internet. That could be an asset to other APRS users in the area, as well as to your weather station.

• Lots of great info thanks! I have tried wifi and it is unreliable due to the range (maybe if I had an outdoor antenna). I'm also hoping to eventually turn my transmitting device into a buoy that would be farther out, so wifi probably wouldn't work. I basically just need to solve getting data from device A to device B, which works with the HC-12 transceivers that I have, but I'm worried about the legality or being legal but seen as strange because I'm sending serial data on the 70cm band (not using the APRS protocol). Is this something to be worried about for my V1 prototype? – kr4sh Mar 10 '18 at 18:48
• Starting to think I should bite the bullet and switch to 900MHz which is a real bummer because I'm somewhat invested in 433MHz already and I got licensed for this (becoming a ham isn't a waste though). I just don't want to interfere with anyone/anything or get into trouble. I want to finish this project and then maybe start looking at getting into proper APRS like you have suggested. – kr4sh Mar 10 '18 at 18:53
• Ah, so you do want to reinvent the wheel, ha ha. I'm not a lawyer, and maybe you should ask a new question about the legality of data modes over VHF/UHF in the US. It seems to me that if you use a recognized mode so that others can reconstitute the digital stream that you're sending, and if you don't encrypt the data and make it so that it can reasonably be recognized as weather data, then I think using the 70cm ham band would be fine. – rclocher3 Mar 10 '18 at 19:30
• Thanks rclocher3. I took your advice and posted a new question: ham.stackexchange.com/questions/10045/… – kr4sh Mar 10 '18 at 20:41