Success! 1M messages

[stevech]

Onr million reliable datagram messages transmitted!   (max msg = 255 bytes)

• Four RFM22s connected to Teensy3 MCUs (a mix of HopeRFM22 and Dorji Si4432 radio PCBs)
• For this test, all are in close proximity - ideal signal to noise
• Network star topology
• One radio/MCU is the hub of the star (server)
  
• Two radio/MCUs are clients that send messages to server and wait for an ACK and then a data message response (which is also ACKd)
  
• One radio/MCU is a "sniffer", receive-only, logging stats of all transmissions of data and ACKs and retransmissions
• Message Traffic:
  
• Clients send message to hub/server containing hello and the temperature per the radio chip, as text. With ACK, this is 2 messages
  
• Hub/server displays each received message and sends to that client a similar temperature report. With ACK, this is 2 messages.
• Sniffer logs each data and ACK message (promiscuous mode).  Displays totals as below.
  

Here's the Sniffer's summary after about 18 hours of running (no restarts)

From           millis        TX    TXACKs      ReTX  

  37        9,025,710   250,740   125,287       106

 154        9,025,707   500,600   250,113       220

 195        9,025,464   250,728   125,280       116

              Totals: 1,002,068   500,680       442

Where the columns are:
"From" is the source address. 154 is the hub so it has twice the load as the others
"millis" is the millis() at the sniffer at time last message was received/logged
"ReTX" is the count of retransmissions due to ACK timeout. Ideally 0 if the clear channel assessment was perfect (no collisions), and the BER was 0.

I didn't see any uncorrectable transmissions (up to 3 retries). But I didn't log such.

Pretty darned fine RF22 library!

Steve

[Mike McCauley]

Nice results Steve.

Cheers.

On Friday, April 11, 2014 04:31:32 PM stevech wrote:
> Onr million reliable datagram messages transmitted! (max msg = 255 bytes)
>

> - Four RFM22s connected to Teensy3 MCUs (a mix of HopeRFM22 and Dorji
> Si4432 radio PCBs)
> - For this test, all are in close proximity - ideal signal to noise
> - Network star topology
> - One radio/MCU is the hub of the star (server)
> - Two radio/MCUs are clients that send messages to server and wait for

> an ACK and then a data message response (which is also ACKd)

> - One radio/MCU is a "sniffer", receive-only, logging stats of all

> transmissions of data and ACKs and retransmissions

> - Message Traffic:
> - Clients send message to hub/server containing hello and the

> temperature per the radio chip, as text. With ACK, this is 2 messages

> - Hub/server displays each received message and sends to that client

> a similar temperature report. With ACK, this is 2 messages.

> - Sniffer logs each data and ACK message (promiscuous mode).

> Displays totals as below.
>
> Here's the Sniffer's summary after about 18 hours of running (no restarts)
>
> From millis TX TXACKs ReTX
>
> 37 9,025,710 250,740 125,287 106
>
> 154 9,025,707 500,600 250,113 220
>
> 195 9,025,464 250,728 125,280 116
>
> Totals: 1,002,068 500,680 442
> Where the columns are:
> "From" is the source address. 154 is the hub so it has twice the load as
> the others
> "millis" is the millis() at the sniffer at time last message was
> received/logged
> "ReTX" is the count of retransmissions due to ACK timeout. Ideally 0 if the
> clear channel assessment was perfect (no collisions), and the BER was 0.
>
> I didn't see any uncorrectable transmissions (up to 3 retries). But I
> didn't log such.
>
> Pretty darned fine RF22 library!
>
> Steve

--
Mike McCauley VK4AMM mi...@airspayce.com
Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.airspayce.com
Phone +61 7 5598-7474 Fax +61 7 5598-7070