Archived Forum

I am trying to answer that, but the spam checker kills my replies, if they contain a link

trying to cheat the spam checker by masking the hyperlinks:

github com/mharizanov/RFM2Pi/tree/master/firmware/RFM2Pi_RF12_Demo/TinySensor_RF12_Demo

github  com/mharizanov/RFM2Pi/tree/master/firmware/Pre_compiled_ATtiny84_RF12_Demo_hex

[Is this what you wanted - RW] :

http://github.com/mharizanov/RFM2Pi/tree/master/firmware/RFM2Pi_RF12_Dem...

http://github.com/mharizanov/RFM2Pi/tree/master/firmware/Pre_compiled_AT...

Ah, yes, thanks a lot. The demo was what I wanted. The hex file I already had.

Best regards!

Hi Martin.

I'm shamelessly hijacking this thread to bring your attention to this issue reported with the standalone python gateway:

https://github.com/Jerome-github/oem_gateway/issues/15

I think I have an easy workaround but I'd like to rootcause, and get a better understanding.

It looks like here

Serial.println();
if(acked)  showString(PSTR(" -> ack\n"));

println() adds a new line character that is not understood by python's serial.readline().

I don't know much about new line character conventions, and serial.readline() function seems limited as regards to this. Apparently, showString changes the \n into \r but readline() understands this as a new line. println must be using another character, then.

Do you have an opinion ? Do you think this is limited to RFM2Pi v1 (software serial) ?

More info in the bug report comments.

Any help/comment appreciated.

Thanks.

Hi.

I posted on this thread yesterday, but my message must have been lost in the anti-spam filtering.

My message was totally off-topic. I wanted to bring Martin's attention to this issue I have with the standalone gateway :

github.com/ Jerome-github/oem_gateway/issues/15

It seems the println() function here uses an end-of-line character that python's serial.readline() does not interpret as such

Serial.println();
if(acked) showString(PSTR(" -> ack\n"));

All details are in the bug report.

I have a workaround but I'd like to understand better, and rootcause the issue.

Any hint appreciated.

Thanks.

Hi.

I posted on this thread yesterday, but my message must have been lost in the anti-spam filtering.

My message was totally off-topic. I wanted to bring Martin's attention to this issue I have with the standalone gateway :

github -> Jerome-github/oem_gateway/issues/15

It seems the println() function here uses an end-of-line character that python's serial.readline() does not interpret as such

Serial.println();
if(acked) showString(PSTR(" -> ack\n"));

All details are in the bug report.

I have a workaround but I'd like to understand better, and rootcause the issue.

Any hint appreciated.

Thanks.

[Edit: anti-spam must have detected my hidden link. Retrying.]

'Newline' is an ongoing problem. There are only two characters involved, but many combinations. Some use <cr><lf>, some <cr>, some <lf>, some <lf><cr>, and sometimes <lf> or <cr> is converted into the other and then it acts on both. I think over the years I've seen all the possibilities. Usually however, it's either the "Windows" <cr><lf> or the "Linux" <lf> that's used, and often both are recognised correctly. http://en.wikipedia.org/wiki/Newline has the details.

Hi Jerome,

I think elyobelyob's boards are running very early firmware, the node IDs that are being reported are > 31, while the latest firmware strips any extra info from the header, so it is impossible to get a nodeID reported as 47 or 52 as seen in the pastebin dump.

mySerial.print((int) rf12_hdr & 0x1F);

Anyway, it is normal to see several 'acks', after all these are not guaranteed to have reached the node that requests them, and it may end up sending a bunch before giving up.

I'm not sure this helped much :)

Thanks for answering.

I don't mind several acks: the following acks are on a new line and are already discarded. My issue is with the ack that is on the same line than the data because the data gets then judged misformed. I have an easy workaround: just add a new test for ack at the end of line, but it is a bit ugly, and I'd rather fix the newline issue correctly.

Maybe new versions don't have this problem and only elyobelyob and other users of this old version should either update their firmware, or patch the gateway with the workaround.

Not sure this is clear if you don't have all the elements in mind...