1
\$\begingroup\$

I am trying to build a "professional" 2 way point to point radio system (like this) to control a RC 1/10 scale car (like this ) using UART, the challenge I am currently facing is finding the right radio modules for the application.

Requirements :

  1. Frequency 100-950Mhz.

  2. Power 27dbm (0.5w) to 30dbm (1w).

  3. Modulation is FSK or OFDM or QAM or PSK or **SK etc. (encryption is nice option not a must)

  4. Multiple units up to 10 point to point units can be operated at the place with interferance ( i think this is called number of channels )

  5. High throughput 10 to 100 packets per second ( packet about 6 bytes)

  6. Two way communication (High speed switching between send and receive)

I have been investigating several IOT wireless Modules ( LoraWan , SigFox , M-Bus ) and can't find one that works for my application, since most of them don't allow high throughput and are designed to transmit at approximately 1 packet/second which is enough for remote sensing applications. BLE and WIFI lack in power, range and frequency.

The only option I have found so far is Xbee ( maybe i am still reading about ) and TinyMesh

So my questions are :

  1. Is my observation regarding IOT wireless protocols correct?

  2. Can some one guide me to the right protocol for low latency communication I require?

    PS: Hopefully this will not be marked as shopping question, I want to understand the protocol or type of network that fits an application :)

EDIT: After Tony's comment about missing specs: cost should be <100$ per Transceiver. Weight and battery power is not an issue as long as it is doesn't consume more than 5W DC (ex: 5v 1A). error correction & detection is a bonus not a requirement. Range is left intentionally Since i mentioned the RF power and frequency.

\$\endgroup\$
  • \$\begingroup\$ Missing in your specs are: budget, mobility, range , weight incl battery and error detect/correction \$\endgroup\$ – Sunnyskyguy EE75 Jul 3 '18 at 19:39
  • \$\begingroup\$ What do you mean by no compliance is required? \$\endgroup\$ – user94729 Jul 4 '18 at 5:30
  • \$\begingroup\$ @Mikey , it doesn't have to pass regulations and be approved for a specific country like US and EU. \$\endgroup\$ – ElectronS Jul 4 '18 at 9:36
  • 1
    \$\begingroup\$ So are you using it moon or somewhere? As far as I know, theres always a standard / specification you need to follow with radios. \$\endgroup\$ – user94729 Jul 4 '18 at 11:47
  • 2
    \$\begingroup\$ I've seen that some short-range 'remote control' applications like this use BLE. I think saying "IoT" usually implies low power and low duty cycle, both of which aren't necessarily necessary for a RC vehicle application. \$\endgroup\$ – immibis Jul 10 '18 at 22:57
2
+50
\$\begingroup\$

This chip meets all your requirements: https://www.semtech.com/uploads/documents/sx1238.pdf

Throughput: You would like 600 bytes/sec broadcasts?.. this chip can do 30,000 bytes/sec, so that should be more than enough

Latency: Since it is a raw modem chip, the latency is just the over-the-air modulation period. At 300kbps, that is ~33 micro-seconds per 1 byte (or 0.2ms per packet).

Network: Since it is a raw modem, you can broadcast to infinite chips. Either make your own protocol, or if you are bad at software, I would just use 2 different chips (1 for RX and 1 for TX, on different frequencies). Each RX + TX pair that has its own frequency pair is a private link, so can make hundreds of "private links" if you want to.

Professional chipset: Yes this is a "professional" chipset. Semtech is a very reputable company with very good support. You should email/meet with their FAEs.

If 2.4GHz is ever an option: I would just use an esp32 (which has custom protocols too, not just wifi). It will just work out of the box. Not sure why you need +27dBm, but LR mode has a large link budget.

\$\endgroup\$
  • \$\begingroup\$ thanks for the well written answer , i just one comment on "NETWORK" . i have tried creating multiple private link on "amateur" transceivers called APC220 ( robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf ) . The transmitter is on the selected frequency however the receiver "sees" everything (not really selective or narrow band i donot know the correct term for this) , thus causing interference if multiple transmitters are working near each other. can you comment \$\endgroup\$ – ElectronS Sep 4 '18 at 22:09
  • \$\begingroup\$ @ElectronS That does not seem correct. Are you sure your transmitter is on a different frequency than the receiver? Looking at the datasheet, pg 10, it even states that if you don't match the frequency, the device will not work: image.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf \$\endgroup\$ – hassan789 Sep 5 '18 at 14:31
  • \$\begingroup\$ @hasan789 , yes i am sure , when frequencies are close ( 1 to 10) mhz apart , I had to use the end of the spectrum one pair at 418mhz and the other is at 455Mhz for it to work , thats why i could not use more than 1 "private" network.. my interpretation is that because they are amateur transceivers their receive RF filters are not very "notch" or selective . \$\endgroup\$ – ElectronS Sep 5 '18 at 15:43
  • \$\begingroup\$ @ElectronS I see! this is called "Adjacent Channel Rejection". APC220 must be quite bad at this. The SX1238 has 73dB of rejection at 1Mhz offset! If your transmitter very very close, you may still have this issue. In practice I have never seen this issue on professional chips. \$\endgroup\$ – hassan789 Sep 6 '18 at 1:27
1
\$\begingroup\$

Actually LoRa works, you can't use LoRaWAN though.

There are even commecially available products, like for example TBS Crossfire runs on the SX1272. The firmware is actually beeing developed for some years now, but basically started at Semtechs Ping-Pong example once, need some tweaking on frequency hopping though to get the duty cycle down.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.