Unexpected behaviour of ER400TRS-02

  
Post any general questions you may have here and we will endeavor to answer them as best we can.

Moderators: radiomadeeasy, WirelessMike

Unexpected behaviour of ER400TRS-02

Postby WirelessMike » Thu Feb 21, 2013 12:24 pm

Note:
This post has been copied from a customer email technical support request and illustrates an excellent question providing comprehensive information on the problem


Dear LPRS support,

We are currently working on a solution to send data from our sensors over a radio link using the ER400TRS-02 module.

At the moment we are facing a phenomenon that is really hard to understand and even after extensive study of the documentation provided in the net we could not find any clue as to what causes it.

Here is a brief outline of our situation.

- Our ER400TRS-02 is connected to an AVR32 uC on a custom PCB.
Firmware of the ERs is 2.01.10.
One module is connected to a sensor (via AVR32), a second module to a host PC (again via AVR32).
- UART baud rate is default of 19200. We are not using handshaking, however the uC can read the busy-signal from the ER.
- The sensor generates datasets of a few kByte, which are collected by the uC. The uC splits the stream into packets (we tested different sizes < 180 bytes).
- The uC counts the bytes it sent to the ER. If 160 Bytes were sent, it waits until busy goes high (i.e. ER starts to transmit), then waits until busy goes low again, before the next packet is sent to ER.
- The last packet is usually varying, but less than 160 bytes, so after pushing all data to the ER, the uC again waits until busy goes high and than low again.
- The receiving ER sees the transmission and receives the packets, then sends it to the uC that forwards everything to a host PC.
- The whole cycle starts new after a longer time when a new dataset is generated from the sensor. So far, the receiving side does not send anything back to the transmitting side. However, this direction is possible and has been tested with short ASCII strings.

The unclear phenomenon:

All full packets (i.e. 160 bytes) are sent and received correctly, even if the total number of packets changes (the datasets vary in size).

However, the last packet (which is less than 160 bytes) only gets transmitted and received, when it is larger than about 135 bytes!

If (by chance) the last packet is smaller than 135 bytes, the whole packet is lost, i.e. the receiver does not see anything.
If the last packet is larger than 135 bytes, it is completely and also correctly transmitted and received.

Furthermore, after a packet is lost, if we manually send an ASCII string (leading to a very small packet size) after a few seconds it gets received correctly, too.

Additional tests we did:

- we can get approximate timing information on how long the busy signal was active on both sides

- at the transmitter:

* the busy signal goes high after 2 byte's time (as written in the data sheet) at the end of every packet we send.
* the busy signal is retracted after some time, this duration is consistent across all packets (i.e. all full packets take about the same busy time, the last shorter packet causes a reduced busy duration, proportional to packet length).

- at the receiver:

* each packet that is correctly received, is preceded by an active busy signal, that lasts proportional to and is consistent to packet length
* However, in case the last short packet was < 135 bytes, nothing is received and there is also absolutely no busy period on the receiving ER module.

- The UART of the uC is fast enough to not stall transport form ER to uC on the receive side. Timing information indicates that we query the UART about 10x faster than data arrives from the ER.

- we tested different sizes for full packets: 180 / 160 / 128 / 96 bytes
The effect stays the same, the last packet only gets sent when its size is close to the corresponding full packet size

According to these tests, the transmit side seems to work as expected.
Even for the last packet, the ER claims to take the time for transmitting it in all cases. However, since there is no busy signal on the receiver when the short packet is lost, it seems that nothing really gets transmitted.

Any help or direction you can provide is much appreciated.

Thank you very much for your consideration.

Best regards,
User avatar
WirelessMike
Administrator
 
Posts: 19
Joined: Thu Oct 04, 2012 10:24 am

Re: Unexpected behaviour of ER400TRS-02

Postby WirelessMike » Thu Feb 21, 2013 12:28 pm

Dear Sir,

The reason for what you see is quite simple.

On the 02 modules the buffer is shared for receive and transmit and so the receiver is only ready to receive over air AFTER it has delivered the last packet. As you are sending the final shorter packet after the transmit has completed, the rf transmit starts before the receiver is ready for it.

Obviously the delivery time is different for each baud rate do the TX cannot have thus knowledge.

Ideally you should wait for the difference in time time to complete for the rx to deliver before sending. ie if you have sent 160 bytes and need to send 130 bytes, wait 30 byte lengths before uploading the last packet.

Does that help?

By the way era400trs version modules use multiple buffers and do not suffer from the restrictions that a single buffer gives.

LPRS Technical Support
User avatar
WirelessMike
Administrator
 
Posts: 19
Joined: Thu Oct 04, 2012 10:24 am

Re: Unexpected behaviour of ER400TRS-02

Postby WirelessMike » Thu Feb 21, 2013 12:34 pm

This is a copy of the response from customer:

It makes a whole lot of sense now:-)

When sending packets of same length the RX had enough time to finish everything before the TX even started to go on air again.

When the last packet is too short, the RX cannot react since it is still busy unloading the previous one and ignores the new transmit completely.
So everything happens sequentially, filling TX-Buffer, sending packet (in full), receiving packet (in full), than unloading to uC (in full), then waiting for new data. Is that about correct?

To be honest i was surprised by the fact that we could sustain the sending of full packets for as long as we wanted to in the first place.

My understanding was that the TX sends packet-wise but the RX simply puts data into its buffer in a FIFO-manner as it receives it, i.e. even if it gets new data on the air interface it would place that in the buffer that is drained by the uC simultaneously. Since we query the UART quite fast i thought the RX would always have enough free space in the buffer to put new aired data into it so the module could sustain a constant data flow.

In conclusion we will either include the waiting period as you recommended above or we will make it more robust by introducing a handshake, i.e. the RX module sends an ACK packet back to the TX module when a packet arrived and the TX does not start a new packet before the ACK.

Btw era400trs version modules use multiple buffers and do not suffer from the restrictions that a single buffer gives.

We will also consider that. A PCB redesign is coming anyways, so we might include the new advanced modules.

Thank you again for the valuable hint and keep up the good work!

Btw, if you find the time i suggest adding a clarification to the user manuals/data sheets about the sequential nature of actions maybe with a timing diagram with all signals (busy/host ready, etc.) showing two subsequent packets.

Best regards,
User avatar
WirelessMike
Administrator
 
Posts: 19
Joined: Thu Oct 04, 2012 10:24 am

Re: Unexpected behaviour of ER400TRS-02

Postby WirelessMike » Thu Feb 21, 2013 12:38 pm

Dear Sir,

Your understanding is perfect !

Just so you know the era400trs is pin and software compatible with the 02 modules you are using. If you wish to communicate with older 02 modules over air you have to send a command to enable it. However you should expect a 30% or more improvement in performance with the new era settings.

We recommend only using era modules on new projects as we have stopped any further development on 02 modules.
eRA modules can handle simultaneous uploads, downloads and RF TX or rx and do would cope with your code without any further modification.

It's better behaviour also makes it more unlikely for the busy pin to set as it is rarely over worked.

Regards,

LPRS Technical Support
User avatar
WirelessMike
Administrator
 
Posts: 19
Joined: Thu Oct 04, 2012 10:24 am


Return to General Technical Support

Who is online

Users browsing this forum: No registered users and 1 guest

cron