TxRxBlinky newbie 'lost packets'

[roffey]

As a newcomer to Moteinos I have 433 RFM69HW units.
Arduino 1.6.5 and RFM69 libraries dated 22/6/2016.
Not an experienced C programmer, but can get around most issues in the end!

So, as a start out I used the TxRxBlinky prog.
Too many lost packets and retries going on .... Frequency set 433.625 ... both units spot on as Trx's(rfexplorer).
RSSI fine .. -28dB. Receiver RFM ports indicating data received ok etc

In the end, turns out to be an issue with the main prog picking up the payload data.

If I do the data comparisons in the RFM69.cpp  absolutely no problems, even with just send mode.
Mind you, delay() is not liked at all in this mode.

I did view 'volatility' issues in another post related to the radio.data ..... is this the reason? Is this why sendWithRetry() is actually used, to make up for this possibility? I seem to remember having array issues like this many moons ago and had to fudge around it somehow.

Do the latest versions of everything deal with this issue?

Maybe everyone starts out like this (always frustrating but you have to pay your dues if you want to get somewhere).

Any help would be much appreciated or pointers to any info/articles etc that would advance my knowledge!

Thanks

[roffey]

Still experimenting here .... same setup.
Got to point in applying everything in the header files rather than the 'sketch', where
everything was nice and fast with no retrys lost packets etc.

So, I went back to the beginning with the original 69 header and sketch. Problems again.
The 'receiver' was ok when I moved lines around ( same code different order), but when I wanted to have data sent back to the 'sender', not so clever. I was using 'acks' (send with retry) requested throughout.

Although data received by the 'sender' would be acknowledged in all cases, only 1 in 3 'if' radio.receiveDone()'s would give a correct response and give up any data.
Changing this to 'if' radio.ACKRequested and pulling data out using this flag, gave 100% response. After collecting the data then sending an ACK, all was well.

Does anybody have any clues as to why this would be?
I'm going to use this flag in the 'receivers' to check that I can place lines where I want them, and continue with what I want to test these units for, but it would be good to have some pointers.

Maybe 1.6.5 combined with the 69 library? I don't really like changing versions just for the sake of it without a good reason to do so.

thanks

[Felix]

The sketches are verified to be OK. You have to make sure your settings match the hardware.
Here's ladyada trying these same examples:

https://youtu.be/n_fJoKhSk3g?t=21m17s

[perky]

There's a few threads on this with similar problems:

https://lowpowerlab.com/forum/moteino/communication-only-works-one-way-regardless-of-device/
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/long-range-parameters-for-rfm69hw-(868-915-mhz)/msg14606/#msg14606

Bottom line is I believe there's a hardware bug in the RFM69 not resetting the receiver properly when transitioning from STANDBY to RX (SLEEP to RX is OK), and also the RSSI reading appears not to function as intended resulting in the canSend() routine timing out after 1 second when sending ACKs.

Mark.

[roffey]

Thank you for these replies ...... I'm sure they will help me figure out what is going on (well, hopefully!).
Just a matter of plugging away, getting a deeper understanding and knowing what workarounds are required.

thanks again.

[roffey]

Just as a note ....
I said I would try the radio.ACKRequested as a flag rather than radio.receiveDone.

So, I have a 'sender' transmitting data to the 'receiver' setup as previously stated.
This data send is requiring an ACK.
On receiving data, this is evaluated and triggers a port. Data is then sent back, also requiring an ACK. This also triggers a port. (Helps scope timings etc.)

Each transaction(sender,receiver) is printing verifications of receiving, flags,Acks, data, rssi, etc.

Using receiveDones() gives random failure to function correctly.
All Ack's are dealt with correctly, but the data received flag is randomly just not raised, leading to data not being sent back. If the data is obviously there, why this flag is not raised is something that I cannot figure out. (Yet)

With just ACKRequested in the sender, only the receiver fails to respond randomly.

Using ACKRequested to signify data has been received (in both sender and receiver), I cannot get it to fail, however I try.

Ah, yes  maybe STANDBY mode in receiveDone and not in ACKReq.
Sorry, a bit slow there.

[Felix]

Ok I think this is drifting away from the main topic title/subject. My main concern is that you can get the TXRXBlinky example running without issues. Are you still having trouble with that?

[roffey]

I'm sorry, it must be that I do not understand the definition of 'lost packets'.

I am trying to evaluate the RFM's in the moteino format as the simplest entry into gaining confidence in their use in a particular project which requires a high level of integrity.
In my many years of related experience, I have always stayed away from the use of rf in this particular field, but I also realise that as technology advances continually, I should always re evaluate and continue along the learning cycle.

TXRXBlinky .... as a simple example that you can get a light to blink and get an indication that data has been received correctly, yes, I can get it running.
What I can't do, however, is be reassured that every time I know that data has actually been received correctly, that the desired response will be acted upon, and that by using different functions, this can be apparently remedied.
Full hardware decoupling exists as does the use of cross coupled Schmitt latching nor gate switch debounce.

In light of the fact that you feel this thread has now digressed .... I apologise for that ... perhaps closure would be best.

many regards.   

[Felix]

roffey,
In regards to integrity, this can be accomplished in several ways. The library offers an "ACK" mechanism where a packet requests a reply from the end node. If the channel is free of interference, settings match the hardware, and antennas are in place and not curled or in some "unhappy" position, the packets will work. The sendWithRetry() funtion will resend and request ACKs up to 3 times by default, or more if you pass an additional numeric parameter. Please see the .h file for the definition or the many examples of how you can use it. Again, if all is OK environmentally and hardware wise, the default call to sendWithRetry should just work with the defaults.
Does this help with the achieving integrity part of your question?

[roffey]

Hi Felix,
I think it's 'hands up' time here to being a typical frustrated starter, who knows what they want but not how to get it! Blame gets cast out of a lack of fundamental knowledge and understanding.
Playing around with the reg, .h & .cpp files along with researching your many posts ( and TomWS ) , plus the Semtech SX1231 prog has helped considerably.

Getting deviation, baud rate, bandwidth etc suitably set for as narrow band as possible, then knowing exactly what happens in an ACK transaction as far as data retention is concerned has been the key for me. i.e. you can't get data that isn't going to be there anymore! hmmmm!

Thanks for sticking with this ... of course, I've got many more frustrations to come as always, but at least it's moving forward and looking positive.

thanks again.

 

[Felix]

roffey,
No problem, that's why this forum is here. There's a wealth of knowledge but it's spread out and the specialty stuff (some of which you mention) is sometimes buried in various threads and you need to dig it up. The library gives an all around default set of settings that works for most scenarios and yields very decent range. If you want to get into low bitrates and bandwidth you will likely need to implement temperature compensation and other techniques to prevent the radio crystals temperature variation to shift your center frequencies to the point where they don't overlap and can't hear each other. It's all a tradeoff with RF, and it's never easy or plug and play like arduinos and blinking LEDs. Although I do try to give the default setting and examples that are verified to work. Then there's what others shared here, projects and approaches to different problems.
Good to hear you're making some progress!