point-to-multipoint comm., encoder/decoder -- how to ?

Wireless & IoT
1

Hi,

Have done a few simple point-to-point RF comm (ISM band) mini projects, with success ranging from just about 100bps without encoder/decoder and without interrupts and upto about 2400bps with Holtek H12E/D encoder-decoder pairs, but without addressing (i.e. all “floating” inputs for the encoder/decoder address lines). I’ve even attempted a similar thing with addressing, but am currently stuck, as I attempt to introduce multi-point communication. Note that I am still in “hobby” domain (well, maybe “hobby++”), and work with very little pro-grade T&M equipment (a decent DMM is all I have).

My problem is that most fixed-code encoder/decoder IC’s work with fixed addresses. While this is no issue on the encoder/TX side, for multipoint, it is an issue on the decoder/RX end, since the decoder IC doesn’t have an “accept all” address concept, i.e. no “wild-card” entry, rather needs an “exact match” address. Which means that, at any given instant, the decoder is ready to accept message from only one TX… so how do I do multi-point.

One solution I have in mind (but yet to implement), is to connect all of the decoder IC address pins to my MCU’s I/O pins, and do periodic-cycle through all “acceptable addresses”, in a time-share fashion. Of course, I need to do it fast enough, not to “miss” any transmit from a TX-node while I am awaiting message from a different TX-node. My challenge is that the node on the TX/encoder end, is a blackbox, rather a box whose logic I cannot change, so I am need to accommodate the multi-point communication changes on the RX/decoder end only. Had it not been so, I would have worried a little less, by increase the period for which the TX/encoder node keeps the transmit on, s.t. it is “long enough” for RX/decoder to cycle-back to it even if missed at the start of a cycle.

Other alternative, I believe is to ditch the decoder IC, and use the MCU. This is not my preferred approach, because of somewhat higher complexity (for me as a programmer), and also higher workload for the MCU. The MCU actually does have a lot to do already. Now, if I were to do it with MCU, my challenge is in figuring out the exact operating “oscillator” frequency of the encoder-IC on the TX-node, because the modulation/encoding is a function of that. With the gear I have, is there a way to know the the operating “oscillator” freq. of encoder ?

Given the 2 options, which one would folks (/experts) here, suggest – and why ?

thanks,

F74

2

Point to multipoint - I’d ditch the kind of radios you’ve been using. Go with IEEE 802.15.4 such as XBee series 1 (not 2). There you have source/destination addressing, error correction, and broadcast packets. The MCU interface can be UART at up to 115.2Kbaud.

Plug and play. The MAC and PHY is done for you. You concentrate on the application, not the transport.

If you don’t want $25 radios with plug and play MAC/PHY, next best would be something like the SiLabs chips used in HopeRF modules for 915MHz (US) or 868MHz (EU). These push error correction and addressing to your application, but they’re a little less expensive.

3

stevech:
Point to multipoint - I’d ditch the kind of radios you’ve been using. Go with IEEE 802.15.4 such as XBee series 1 (not 2). There you have source/destination addressing, error correction, and broadcast packets. The MCU interface can be UART at up to 115.2Kbaud.

Plug and play. The MAC and PHY is done for you. You concentrate on the application, not the transport.

If you don’t want $25 radios with plug and play MAC/PHY, next best would be something like the SiLabs chips used in HopeRF modules for 915MHz (US) or 868MHz (EU). These push error correction and addressing to your application, but they’re a little less expensive.

@stevech, thanks. Point taken. I had actually looked at those as alternatives a while back.

  • - Reason for not picking the Xbee is that they are really very expensive compared to the 433MHz modules (5x the price in retail).
  • - The other bare-bones modules, don't seem to come with excellent documentation or (community/) support, so for someone who is nowhere near being an RF expert, I think it'd be stretching my capabilities bit too far.
  • - Finally, the most important deal-breaker is the fact that I need to work with bunch of existing elements (which I cannot change), already talking 433MHz-ASK/OOK.

    • On the other hand, I know that people have managed to pull-of 433MHz ASK/OOK based point-to-multipoint communication. Although, I don’t see any hobby projects in that bunch.