Hello everyone,
I have some moteino working around the house quite nicely, however the other day I noticed that although the messages were getting through, the ACK was not working.
As testbench: I have got 2 moteinos, both using external FTDI as I bought the moteino without integrated FTDI. They are running the PiGateway and the Node sketches. I have just disabled the ATC_RSSI in case I got any improvement (which I did not).
(i am using the HW version 915mhz)
As you can see, messages are getting through but ACK only get recognized rarely. I have changed the NETWORKID to 100 so I dont get messages from my other network 200.
Any idea why this might be happening?
I have tried:
- lowering the serial baudrate from 115200 to 19200
- disabling ATC_RSSI
- changing the "node" sketch so it sends every 5 seconds instead of every 1 second
Please help me understand the issue.
thank you all.
(please if there is any test I can do to help troubleshoot)
I suggest you attach your two sketch files so we can look at the code. Screen shots aren't useful for examining code.
In general, if you're using the standard example files as a framework, lowering the baud rate of the gateway makes things worse, not better, because the gateway is busy printing the message rather than ACKing. Always ACK first, then print (process) the data, so that the time between receipt and ACK is the lowest possible value. Of course, this means that you need to save the received data before ACKing since it's possible to get overwritten once you ACK.
Also, what it the time between retries on the node side? Are you using the default (which is 40mS)? Try increasing that in 40mS increments and see what effect it has.
Tom
Thank you Tom as always for trying to help!
I have attached the two files. They are fresh from the github repository I have just made the following changes:
- Gateway: change networkid to 100
- node: change TRANSMITPERIOD from 200 to 1000 to be able to follow it in the serial terminal
- node: change frequency to 915
- node: tried different ms timeout but no difference, even with a huge 300ms --> if (radio.sendWithRetry(GATEWAYID, payload, sendSize,0,300))
thank you for your time checking this out. let me know any further information I can give you.
(i understand your explanation on the serial baud rate, now i have left it as in the github example were the gateway is at 19200 and the node at 115200. i guess it should work)
Ok now i am confused.
I just noticed I was uploading the PiGateway and not the Gateway.
Just tested the Gateway sketch and works perfectly. But why????
I have always used the PiGateway in all my home system, always have seen this ACK problem, now I discover that with a different Gateway sketch it works.
Could you help me understand?
thank you!
ok, found the lines which cause the problem:
// inputLen = readSerialLine(input);
// inputstr = String(input);
// inputstr.toUpperCase();
but this PiGateway sketch is coming from Github, so it is supposed to work as it is.
if you have any idea why this is happening to me and nowone else?
thank you
(below a snapshot of the PiGateway and Node code. The PiGateway has the 3 lines above commented out)
I can't answer about the PiGateway, I've never used it, but if it uses Linux 'IO', then you could get a cup of coffee while you're waiting for a turnaround (JK, but it is not direct IO).
Re your comment:
Quote- node: tried different ms timeout but no difference, even with a huge 300ms --> if (radio.sendWithRetry(GATEWAYID, payload, sendSize,0,300))
Well, perhaps if you actually had a retryCount other than 0 in the parameters it might have tried to wait up to 300mS...
Tom
Try changing your call to readSerialLine to the following:
readSerialLine(input, 10, 64, 100);
I think the default timeout of 1000 milliseconds might be too long.
Quote from: TomWS on December 05, 2017, 06:44:53 PM
I can't answer about the PiGateway, I've never used it, but if it uses Linux 'IO', then you could get a cup of coffee while you're waiting for a turnaround (JK, but it is not direct IO).
Re your comment:Well, perhaps if you actually had a retryCount other than 0 in the parameters it might have tried to wait up to 300mS...
Tom
hello Tom,
In the tests above I am using windows 10, so in this case no Linux IO involved.
So my question is, how is it that noone else has this problem? I guess this code is working correctly for at least Felix.
(thank you for the retryCount, you are right)
has anyone else tried the PiGateway and experience this issue? or can explain why the readSerialLine is causing this problem?
thank you !
The PiGateway.ino sketch is tailored for using with the MightyHat or with a Moteino that acts as a gateway to a network which interfaces to the PiGateway project (https://lowpowerlab.com/guide/gateway/).
The Gateway.ino sketch is just a simple send/receive 101 sample that is meant to be paired and work in tandem with the Node.ino sample.
Hello Felix. I understand the idea of each of the sketches however I don't understand why the PiGateway would not work when connected to a simple moteino. What reason might there be for the readSerialline to take so long to block and prevent acknowledge to work? I antually need to have the read serial in order to send messages both ways from the gateway. Thank you for your help
The sketch works, that is for sure. I use it myself and others who use a Moteino/MightyHat+Pi as a gateway.
Why it does not do something you expect I can't be sure ... but delays are specified in RFM69_OTA.h, perhaps the 1sec delay reading is causing your problem:
uint8_t readSerialLine(char* input, char endOfLineChar=10, uint8_t maxLength=115, uint16_t timeout=1000);
Make sure you got the latest libs...
Thank you Felix. I am indeed using the latest library and examples. I have the node connected to a Windows pc via a serial converter, you are probably using it directly in the mightyhat to a raspberry. Could this be the reason? Any tests you can suggest to troubleshoot? There is no doubt the sketch works for you, just want to understand what is happening and learn from it. Thank
Try to call readSerialLine() with a short delay:
readSerialLine(buffer, 10, maxLength, 30)
That should free up your loop to check incoming packets a lot more often.