Long range, low latency telemetry? - Page 1
Forum section: electronics / rf-microwave

author: enjoy.cowboy
author_rank: Contributor
timestamp: April 15, 2019, 02:29:26 pm
content: Dear colleagues....I work on a small university model rocket team, where I was tasked with developing a telemetry system to track our rockets in (as close as possible to) real time during the whole flight. I looked into LoRa and was immediately turned away by its latency and low data rate. I am a complete newbie to the whole RF business, so I am completely lost in what modules to look for (or design my own/hack around something?), but the design requriements state around 10km range with data rate in the order of tens of miliseconds. Google-fu shows modules like the RFD900 which is very expensive. Any other recommendations? Also, any traps for young players to avoid?

author: PETER ERSKINE
author_rank: Newbie
timestamp: April 16, 2019, 02:43:43 am
content: Quote from: enjoy.cowboy on April 15, 2019, 02:29:26 pmdid you google - long range low latency telemetry transmitter.Here's one...https://www.ebay.com/itm/FrSky-R9M-900mhz-Long-Range-Low-Latency-Telemetry-Transmitter-Module-USA-STOCK-/142961156978I did and found dozens of options.... do it and select what works for you unless you want to build your own then the members here can help.

author: beanflying
author_rank: Super Contributor
timestamp: April 16, 2019, 03:29:11 am
content: As per Peter's link. Look at the Radio Control / Drone / FPV based technologies there is plenty of real time options that will easily do what you need an even include video depending on your needs and eventual setup.I have an older Eagletree loggerhttp://www.eagletreesystems.com/index.php?route=product/category&path=63which won't meet your spec but you may get some good ideas of what is possible. Some better Aerials would see you getting toward your 10km.https://hobbyking.com/en_us/radio-servos/radios/radio-sensors.htmlfor more FRsky and similar.No nothing about these guys but I have seen a few youtube videos of similar systems in use.https://www.fpvmodel.com/50km-long-range-fpv-sets-for-fixed-wings_g997.html

author: Psi
author_rank: Super Contributor
timestamp: April 16, 2019, 06:13:38 am
content: It might be cool to add some redundancy. Have two RF links, eg 433mhz and 900mhz. That should be more reliable than a signal link and it doubles the datarate over a single system.50% slower data is better than no data.Also, avoid falling into a trap when on delivery of the system the shit hits the fan because total system latency is 100ms and they argue that they paid you for a 10ms system.With the 90ms difference coming from their flight controller and their ground processing systems. i.e.Totally separate from your part of the project, which did meet 10ms spec.These sort of issues can crop up when one department expects a particular specification and your project is to meet said spec but no one considers the whole system.So make sure the latency spec is just for your part and they know total latency is out of your control.Or at least keep an eye on the other areas of the project, (flight controller, ground processing) so you know roughly what total latency will be sooner rather than later.

author: a59d1
author_rank: Regular Contributor
timestamp: April 16, 2019, 05:36:45 pm
content: There is nothing on the market cheaper than the RFD900. There simply aren't enough sales of rocket telemetry radios (who knew?) to justify any company offering a full system for less than $100 a side.QuoteWhat does this even mean? 100 bytes per second?

author: enjoy.cowboy
author_rank: Contributor
timestamp: April 16, 2019, 06:21:29 pm
content: Quote from: a59d1 on April 16, 2019, 05:36:45 pmSlight conceptual brain fart there. I meant something that transmits in a high rate. Since im monitoring 14 data fields with 4 bytes each, i think something in the order of 100kbytes/sec should be ok.I was also wondering if it was feasible to hack around a walkie-talkie to make it transmit the output from my sensors instead of the microphone input

author: Circuitous
author_rank: Unknown
timestamp: April 16, 2019, 06:34:53 pm
content: What about using the nRF24L01 trancievers? They're small, cheap, have high data rates, and there's tons of examples.https://randomnerdtutorials.com/nrf24l01-2-4ghz-rf-transceiver-module-with-arduinoSent from my SM-G892U using Tapatalk

author: splin
author_rank: Frequent Contributor
timestamp: April 19, 2019, 02:07:44 am
content: The big question that needs answering first is "does this need to be legal with respect to the local radio usage regulations?". If so, does it need to use unlicensed (ISM) frequencies or are special licences available?In Europe for example, this would probably be difficult, if not impossible, using the 433MHz and 868MHz unlicensed ISM bands because TX power limits and duty cycle and/or channel bandwidth are severely restricted - no chance of using 1W+ transmitters. If transmitting continuously, as you want to do, Tx power is likely limited to < 10mW for most bands (and perhaps rather less - I haven't checked recently) except perhaps for channels used for RFID tag scanning. For high speed low latency links then 2.4GHz and 5GHz bands are the only choice as far as I know.You need to start by investigating your local radio regulations to see what you are permitted to use. If you aren't concerned at conforming to the regulations then of course use whatever you can get at the right price.A big advantage you have with rocket telemetry is that you have line of sight operation and few to none of the problems of blocking and multipath interference which cause big headaches for ground based links. This means you can probably get away with much lower TX power than for ground links. And when your rocket gets up to a reasonable height then interference from other transmitters should also become a much smaller problem than usual assuming your receiving antenna is reasonably directional and tracks the rocket.

author: enjoy.cowboy
author_rank: Contributor
timestamp: April 19, 2019, 06:04:36 pm
content: Quote from: Circuitous on April 16, 2019, 06:34:53 pmWe've had no end of problems with these NRF modules. We tried it for a wireless ignition mode as required for a few competitions and never got reliable operation.Quote from: splin on April 19, 2019, 02:07:44 amI'd rather stay within the ISM band (902MHz to 928MHz). Our launch site is near the final approach of a local airport, and if we ever got in trouble with the law, it would take quite a lot of explaining. Current law states that we are allowed up to 400mW of EIRP for unlicensed broadcast. There is currently no legislation on transmission duty cycle and channel bandwidth. I had a brainwave recently and thought of maybe and SDR transmitter with something like a DSPIC, although i'm not sure how i would build the packets for transmission.

author: splin
author_rank: Frequent Contributor
timestamp: April 21, 2019, 12:16:31 am
content: Note that receiver sensitivity figures that I quote are from the transceiver IC datasheets. These are generally the best possible values which can be achieved under ideal laboratory conditions and may or may not be achievable in practice under realistic conditions. Transceiver module specifications, such as the HopeRF RFM26W, typically seem to quote the IC datasheet figures, so real world performance may fall short by a few dB.Quote from: enjoy.cowboy on April 19, 2019, 06:04:36 pmOk, that gives you a lot of flexibility. To calculate the link budget you need to know the path loss (signal attenuation TX to RX), TX power, RX sensitivity and TX and RX antenna gain. So starting with the RX sensitivity, this is limited by the noise performance of the receiver and the data rate - which you stated to be 800Kbs.The Silicon Labs Si4463 transceiver is a reasonable candidate, used in the low cost HopeRF RFM26W module. It has a 100mW (20dBm) transmitter, and an RX sensitivity spec of -97dBm for GFSK 500kbs mode, which isn't far off your requirement. You could improve on this with a high performance, ultra low noise receiver but it is likely good enough.I used radio mobile,http://www.ve2dbe.com/rmonline.htmlto simulate a link with two locations 1km apart with transmitter antenna height at 10km and receive antenna height 2m and frequency 905MHz. This gave a path loss of 112dB. So with a 20dBm transmitter and 0dBi TX and RX antenna the RX signal level would be 20dBm - 112dBm = 92dBm. This is 5dBm higher than the Hope RFM26W RX sensitivity spec so it looks like it might work.5dBm is not a very big margin for reliable operation but you can improve that using higher gain antennae - 0dBi isn't unreasonable for the rocket's TX antenna as it will need to be light weight but a 2dBi antenna should be light enough. The RX antenna can be much larger; 6Bi omni directional antennae are cheap enough and higher gain directional antenna (Yagi) are easily available (but beware cheap Chinese antenna dBi which are frequently bigger than everybody elses and their MHzs may be different as well!) . Adding an LNA to the receiver should gain another 3dB or more as the Si4463 front end is a bit noisy with a noise figure (from memory) around 6 or 7dB whilst a good LNA should be around 2dB or less. Potentially you should be able to improve the 5dBm link fade margin by at least 12dB without going to extremes.I would suggest avoiding high power transmitters if possible as they tend to be inefficient and thus consume a lot of power and increase the probability of interference with other users of the band (and possibly attract unwelcome attention).Another option to increase the margin is to reduce the data rate; I'm fairly sure that all 14 monitored channels won't all be carrying pseudo-random, uncorrelated data, so a significant amount of compression may be possible. For example the altitude data (hopefully!) will be comprised of monotonically increasing, accelerating values until apogee, so just transmitting the difference from previous values will save some bandwidth.Yet another option is to use multiple transmitters operating on different channels, allowing each to operate at lower data rates and thus better link budgets due to the higher RX sensitivities at lower data rates. Although it means more hardware, it adds redundancy at both the TX and RX ends and the most valuable data can be duplicated across two or more transmitters for even better reliability.Other radio modules are available although not all support such high data rates. One worth mentioning is the AxSem AX5043 (now owned by Onsemi). It has a maximum data rate of 125kbs but it has a better (specification) receiver sensitivity of -108dBm compared to -105dBm for the Si4463. 230MHz and 433MHz 1W modules are easily available from Aliexpress but you might have to buy the manufacturer's development modules for 900MHz.Another is the Semtech Lora chips including the SX1262 which supports 300kb/s FSK modes as well as the slower Lora. RX sensitiity is specified as -104dBm at 250kb/s. 1W modules are available from Aliexpress, such as Ebyte's E22-900M30S for $7.QuoteCould be fun, but quite a lot of work. Reading the datasheets for the transceiver chips including the Si4463, SX1262, AX5043, CC1125 (a TI equivalent to Si4463 but less popular?) etc. will give you a lot of information as to how the packets are designed, including preambles to allow the receiver to adjust it's AGC and to synchronise its clock timing. In your case it should be pretty simple if you use continuous transmission as the receiver should maintain timing lock once acquired so use any protocol you like - perhaps as simple as fixed size blocks with CRCs and inter-block sync patterns to recover data bit timing and block synchronisation if lost. Obviously this doesn't apply if you need to operate half-duplex to provide an uplink, in which case I'd stick to the transceiver modules.Good luck and please let us know how you get onPS. Be aware that RX sensitivity figures are specified at different bit error rates by different manufacturers so not directly comparable, typically @ .1% or 1% BER - the latter will give a better looking sensitivity figure of about +2.5dBm.PPS. Depending on your budget, investing in a $100 N1201 or N2201 VNA may be a good idea to check the tuning of your antenna - watch some of Andreas Spiess's videos including:

author: enjoy.cowboy
author_rank: Contributor
timestamp: April 23, 2019, 11:38:14 am
content: Crikey moses, thats just what the doctor ordered!Quote from: splin on April 21, 2019, 12:16:31 amWe have someone on the team developing a 4dBi patch antenna which will go mounted on the bulkheads. Weight isnt as much of a constriction as volume right nowQuoteWhat would be a safe margin?QuoteIts not all uncorrelated data, but it kinda is. I intend to transmit them raw and process it on the receiver side, since its already kind of what we do. We used to dump the flight reports to an SD card in raw csv and stick it into a matlab script to convert and plot. For the telemetry system, Ill probably just read it into matlab straight from the serial port and convert it in realtime.The flights are currently only a few minutes long, so the more data we can gather from it, the better. We were running the system from a puny ATMEGA328p, so any clock cycles we could save from conversion would imply checking for the freefall state more often. The plan is to upgrade to an ARM Cortex M3 with a real time operating system to detect a freefall state to trigger the parachutes and gather flight data to develop a robust stabilization module. Wheels within wheels...I'll probably stick with the Si4463, which is very cheap and there are some ready made modules built out of pure Chinesium we can just stick into our homemade PCB while we develop and gather funds for spinning the board with the whole control system and main processor boards

author: splin
author_rank: Frequent Contributor
timestamp: April 24, 2019, 01:01:46 am
content: Quote from: enjoy.cowboy on April 23, 2019, 11:38:14 amIt would be better, if you can still achieve your desired link budget, to use an isotropic radiator (0dBi) so that the signal strength doesn't vary much with the attitude of the rocket - antenna gain is achieved by making it directional which isn't ideal if your rocket were to change attitude significantly relative to the receiver or worse were to tumble. Even with a perfectly omnidirection antenna, some signal obstruction may occur due to the rocket body obstructing the signal in some orientations.Quote20dB is a decent fade margin but 15 or even 12dB may well be adequate. 20dB for a ground based link has to allow for all sorts of signal degradations, including obstructions such as the growth of vegetation and tree foliage, antenna corrosion/water ingress and multi-path interference caused by reflections from the ground, buildings, vehicles etc, which can change over time. In your case most of these should not be a factor - except reflections from airplanes approaching the airport perhaps?Thus a lower minimum margin should be acceptable when the rocket is high enough - if it were to come down 10km away then those other factors start to come into play as the rocket descends.QuoteFair enough, but lowering the data rate is where you can get the biggest gains in link margin. The different telemetry streams may be largely uncorrelated but it seems to me to be highly unlikely that they will all have a signal fully occupying the 32 bit dynamic range allowed by the 4 bytes/channel specified. Not many sensors that I can think of have a noise performance to even require 16 bits - 12 bits is likely enough for the vast majority unless you have some very sophisticated instruments.For example, the ADIS16470 is a wide dynamic range MEMs IMU (and not particularly cheap) but the noise levels mean that the gyros only provide about 12 bits of dynamic range and about 15 bits for the accelerometers; there is no point in sending noise on the downlink. In addition it is extremely unlikely that the signals will exhibit full range excursions thousands of times per second. Much of the time the varying part of of the signal will occupy only a fraction of the total dynamic range so 8 bits may be enough most of the time. But bear in mind that the Ariane V failed catastrophically because a signal had a larger dynamic range than expected...QuoteOk, so decent data compression could be tricky on an ATMEGA. You can get an STM32F103 'blue pill' board for around $1 - spend the development effort on that rather than a high performance radio link, especially as you're planning to do that anyway. I can't see you'd need an RTOS for what should be a relatively simple application (but obviously I don't known what you're doing with it) and it wouldn't hurt.QuoteDo look for ready made libraries though as they are quite complex with a lot of configurable parameters. Don't assume that your choice of transceiver modules will meet Silicon Lab's datasheet performance so be prepared to do lots of testing. For example, poor layout might cause noise issues or poor antenna matching networks, due to poor design or component tolerances, cause more signal loss than expected.I don't know if you had planned an uplink but it might be a good idea as you can use it to send the ground station's recevied signal strength (RSSI) value up to the rocket which would allow it to reduce the data rate and improve the link reliability if necessary (ie. if the RSSI gets close to the minimum required) - better to lose some data than all of it if possible. Or more simply the ground station can send a command instructing the rocket to adopt a specific data rate. And remember that there is no reason to assume that the up and downlinks have the same link margin due to differing tx power, rx sensitivity, local interference etc.

author: enjoy.cowboy
author_rank: Contributor
timestamp: April 24, 2019, 04:46:13 pm
content: QuoteYeah, the antenna will go mounted on the bottom bulkhead facing down. The only major body part the signal has to pass through is the motor, no biggieQuoteWe use a 9DOF IMU that has all 3 sensors working with 16 bit registers. The 32 bit number came up since i store data like the pressure sensors value and time in double precision floating point variables, which on the AT328 take up 4 bytes. Maybe I can encode them differently to take up less space for transmission?QuoteThats exactly the board we're upgrading to. I chose the blue pill instead of the maple mini due to easier implementation of RTOS. It will have a thread constantly monitoring the altimeter array for decreasing altitude to trigger the parachute switch instead of waiting for another read->convert->check->dump cycle on all the sensors. I'm still trying to figure out a way to do it faster, but obviously we were bottlenecked by the SD card speed.QuoteI hadn't planned for an uplink, since I was thinking that the only need for an uplink would be for issuing actuator commands, which wouldnt be the best way to control a vehicle going at around 800kph. But now you had me thinking about implementing some sort of acknowledge packet to adjust data rate.Project update: Order placed for the RF modules. Development for the main processor upgrade halted since we have a launch scheduled for May 1st.EDIT: Regarding the IMU readouts: The 16 bit values are converted into ~useful units, as in meters, degrees etc. But yeah, we're nowhere near enough needing a precision of less than one degree and one meter. Hmmm...

author: splin
author_rank: Frequent Contributor
timestamp: April 24, 2019, 11:32:44 pm
content: Quote from: enjoy.cowboy on April 24, 2019, 04:46:13 pmBut you didn't address the gain issue. You may get +4dBi when the rocket is travelling directly away from the receiver but if it tilted over, by say 45 degrees, you might then get -4dBi or less. If you were relying on the 4dBi gain for the link to work, then it very likely won't work in this situation when you especially want the telemetry - if for no other reason than for the post-mortem analysis of what went wrong. Better to use a 0dBi antenna if you can.QuoteIt seems unlikely that you need to send the time to the groundstation which knows what time it is! Absolute time is unlikely to be needed - post flight analysis of the data only needs to know the relative time between data samples which ought to be synchronous with a fixed internal clock, whose's rate will be known. You'd only have to send time data if you have some data whose timing precision needs to greater than the main sensor sample rate (of around 600us?).And why on earth would you want to convert a 16 bit integer to floating point before transmission? It will simply waste processor time performing the conversion and double the size for no gain whatsover. It's also very likely that those 16 bit values are only 12 or 13 bits of data plus 3 or 4 bits of noise. There's no point in transmitting noise - the receiver has access to plenty of its own and doesn't need anymore!Saving 20 to 25% is quite worthwhile and trivial to do, but you can go further as most of those useable 12 bits of data won't change much from sample to sample so its likely you only need to transmit 6 or 8 bits of difference data (ie. deltas) most of the time. For example the vertical accelerometer signal will change from zero to its maximum (or near maximum) just after the motor is ignited but subsequently the rate of change of acceleration (dV^2/dt) will change relatively slowly - unless the rocket hits something hard like an airliner on finals!Thus you probably only need to send 4 or 5 bits of acceleration data most times, representing the difference between the current and the previous absolute acceleration values. When you need to send a larger value that won't fit in the 4 or 5 bits, you can use an additional flag bit to indicate that the value is a full length, 16 bit, value before reverting to the shorter delta values for subsequent samples. The average data rate is thus much lower than sending the full values every time.I expect you could get the required downlink rate to 125kb/s or less. That would give you 8dB gain in receiver sensitivity over 500kb/s.The above data compression schemes are pretty simple and an ATMEGA should have no problem handling it (especially without any floating point processing). With a Cortex M3 you could use more complex data compression schemes such as run length limiting, or even ZIP, BZIP/LZMA etc but the law of diminishing returns means it may not be worthwhile.QuoteI presume that you are collecting and dumping sensor data to an SD card limited by the card's sustained write speed (^MB/s for a class 6 card) but sending a subset of that data to the groundstation becaiuse of the limited downlink data rate? It seems to be so simple (from a timing point of view) that an RTOS is unnecessary. IE.:1) Wait for the clock triggering the next sensor sampling cycle.2) Read and process each sensor3) Store data in SD4) Check altitude data and deploy parachute if necessary.5) For every Nth main loop iteration send data to downlink6) Go back to 1 awaiting next clock cycle.QuotePerhaps better to keep it is as simple as possible until proven reliable, then 'upgrade'. OTOH you know you want that remote destruct featureQuoteDon't forget to post the videos!

author: Psi
author_rank: Super Contributor
timestamp: June 15, 2019, 04:17:14 am
content: Wow that N1201SA thing is cool. I want a version that does 5.8Ghz so badly!!