Skip to content

JDY-40 Wireless Broadcast

A commenter on a previous post asked about JDY-40 broadcasting to multiple nodes, where only a specific remote node will reply to the broadcast. This project shows a way to setup a three-node JDY-40 network with one hub and two remote nodes.

Python and Arduino code can be found here.

Network Architecture

Each node in the network has a unique identifier. In this example there is a hub named “hub” and two remote nodes named “uno” and “nano”. Each broadcast message contains a value that specifies which node is the intended destination. The hub always initiates communication and the intended destination node replies to the hub.

The datalink layer of the JDY-40 module natively broadcasts to all nodes on the same frequency, RFID, and Device ID (more on those parameters in this post). This means that all JDY-40 nodes are actually receiving all messages. The key to this setup is that each node will ignore any messages where the “destination” field does not match it’s own identifier.

Message Format

The messages are formatted as json text. Here is an example of a message that the hub broadcasts when it wants the “uno” node to respond. It specifies the source as itself, and the node named “uno” as the destination.

{
  "source":"hub",
  "destination":"uno",
}

The “uno” node in turn, will respond with a message which designates the source as itself, the destination as the hub, and whatever data it has to share. In this case it returns a randomly generated temperature for testing purposes. In an real use case the hub message could include specifics about the requested data from the node using additional json fields. Similarly, the remove node reply message could easily be expanded with additional fields to provide more data.

{
  "source":"uno",
  "destination":"hub",
  "temperature": 62.3
}

The “nano” node will ignore both of these example messages because the destination value in either case does not match it’s own name.

When the hub sends a message with the “destination” field set to “nano”, the Nano node responds with a similar message as the Uno node. Though in a real use case, the nodes could each have a different message format depending on what kind of data they have to report to the hub.

Running The Test Setup

The test setup uses an Arduino Uno (yellow board) and Arduino nano (striped board on breadboard) as the JDY-40 nodes. A laptop sends serial data to the hub JDY-40 through an FT232RL USB to serial adapter.

Here is the terminal output when running multicast_hub.py. It shows what messages were sent along with the reply message from each node. Two messages are sent to the “uno” node, then two messages are sent to the “nano” node.

Hub started. Enter commands in the format: destination payload_text
Press Ctrl+C to exit.
> uno
Sending: {"source": "hub", "destination": "uno", "payload": ""}
Reply received: {'source': 'uno', 'destination': 'hub', 'temperature': 60.7}
> uno
Sending: {"source": "hub", "destination": "uno", "payload": ""}
Reply received: {'source': 'uno', 'destination': 'hub', 'temperature': 64.9}
> nano
Sending: {"source": "hub", "destination": "nano", "payload": ""}
Reply received: {'source': 'nano', 'destination': 'hub', 'temperature': 70.7}
> nano
Sending: {"source": "hub", "destination": "nano", "payload": ""}
Reply received: {'source': 'nano', 'destination': 'hub', 'temperature': 74.9}
> 

Conclusion

The JDY-40 broadcast test worked well and can easily be expanded to include additional nodes. The json message format also allows for various types of data reporting from the remote nodes.

One of the issues I occasionally ran into was data dropping which resulted in incomplete messages received. These tests were all done at close range so data drop was rare. For use in longer range projects, the network would need to be more reliable. This could be done by adding handshaking such as an ACK message, and error code checking such as a checksum value.

In order to setup multiple independent networks, each network would need to be on a unique radio channel. To avoid potential interference, it is best to set each network several channels apart.

Leave a Reply

Your email address will not be published. Required fields are marked *