I'm using the EterNode and I can't see any sniffed traffic.

Jee Labs Talk » How can I fix ... ?

I'm using the EterNode and I can't see any sniffed traffic.

(18 posts) (4 voices)

Tags:

No tags yet.

bmj

I'm using the EtherNode code under: Examples=>EtherCard and I can't see any sniffed traffic but all other functions works!
I can visit the nodes home page. The uptime increases. I can transmit from the webpage to ID0 or ID16 on group 212 @ 868Mhz and it is received on ID16. I know that there are valid RF-traffic for group 212 (eg. from node ID3 room board as node ID16 (running RF-Demo) shows all traffic. If I remove the EtherCard and install RF-Demo on that node both receiving and transmitting works.
If I install the EthernetCard STILL running RF-Demo received package becomes garbled, is this normal due to IRQ conflicts etc???
I'm using Arduino IDE 21 and the latest of the libs in zip-format from JeeLabs I'm using a JeeNodeV5
I'm I missing something obvious? If not, I'm going to build an other set to morrow to eliminate faulty parts etc.
//WR B Mathias Johansson

Posted 14/01/2011 15:05:09
jcw

> If I install the EthernetCard STILL running RF-Demo received package becomes garbled, is this normal due to IRQ conflicts etc???
That might well be the case.
It doesn't sound like a hardware problem, since you've got all the pieces validated with the different trials you describe.
Something like this might happen if interrupts aren't working, but then you wouldn't be able to send anything out either.
Weird, I'll think a bit more about this. Don't quite understand what could be causing this, sorry.

Posted 14/01/2011 17:36:16

bmj

I have assembled EtherNode number two and the same problem persists.

I have put some debug code in to (an otherwise unaltered) "etherNode" sketch:

    if (rf12recvDone())
    {
        Serial.println("Something recived");
        if(rf12crc == 0)
        {
            Serial.println("CRC OK");
            if((rf12hdr & RF12HDRCTL) == 0)
            {
                Serial.println("HDR OK");

When the node running RF-Demo reported:

    OK 35 251 64 149 0
    -> ack

The EtherNode sent to serial:

    Something recived
    Something recived
    GET / HTTP/1.1
    Host: 192.168.0.12
    Accept-Encoding: gzip
    Referer: http://192.168.0.12/
    Accept-Language: sv-SE, en-US
    User-Agent: Mozilla/5.0 (Linux; U; Android 1.0.0; sv-se; NTM7U Build/ECLAIR) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
    Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
    Accept-Charset: utf-8, iso-8859-1, utf-16, ;q=0.7

Obvious the packages is garbled on the etherNode even that both nodes is about 400mm apart on my workbench (yes I have moved them around to test). And sins I have tried two different etherNode (and the tests in earlier posts) I role out bad soldering on my part (-;

Jean-Claude could you test the code/hardware on your side and check if you have checked in the last version of the code and if you have updated the ZIP:s?

WR// B Mathias Johansson

Posted 16/01/2011 09:58:34

smihai

I have the same problem here with my new EtherNode (i received mine just after new year) maby it's just a problem with this new batch...
Also i can send packets from the node but does not show anything received.

Posted 16/01/2011 15:38:47
bmj
It is god (in a bad way) that you to have this problem to, that gets me (use) a better chance to solve it!
I don't think it is a hardware problem (but I could be wrong). My test so far points to a software problem. One off my etherCard is old by the way (I just assembled it recently). But it might have something do do white nodeV5. I will investigate further along this lines:
1. Use a nodeV4 1. Compare the SVN code against the code in the zip:s. 1. Power the system from something other than the BUB:a. 2. Print the received pkg. to eliminate a false negative in the CRC routine. 3. Test with and without serial output enabled (serial can some times tax resource and make the CPU "go funny") 4. Dig into the receiver part of the code.
```
     
```
What version of IDE, libs, nodes etc. are you using? Did the etherNode sketch ever work for you or is this the first try as it is for me?
Posted 16/01/2011 20:52:11
jcw

I'm surprised by the problems with the EtherNode sketch. I'll look into it later this week.

Posted 17/01/2011 00:05:20
smihai

@bmj: it failed the first time i assembled it. also tested with JN v5 only.

Posted 17/01/2011 08:36:21
smihai

Still not working for me:
1. tried with a V4 node
2. powered the device from an independent power supply
3. tried multiple groupID's and node ID's ... just in case.
still i can send data from the ethernet node and it is received by the receiver node
Any other sugestions... (i just finished making my stand alone box for ethernet and i'm eager to be able to install it permanently (i'm wondering what sort of uptime this device will be getting :D )

Posted 18/01/2011 17:42:33
bmj

I did not have as much time to debug this as I had hoped. If we combine the result of our test the software is to blame.
My suggestion is that you first disable serial output, if that dosn't help its safe to insert println at various places (watch out for time critical code blocks. Use a variable in such cases and print it later on) and check at what point the corruptions occur and find out what causes it. I help with this as soon as I get some free time (tomorrow I hope).
If that dosn't help its time to bring out the memory-osc. and the logic-analyser and sniff the traffic on the PCB and compare against the datasheet.
One more thing. If you are using code form the Zip-files check out the last code from SVN and test it or compare it to the zips. Maybe Jean-Claude forgot to (re)build the ZIP:s???

Posted 18/01/2011 20:23:16
jcw

> Maybe Jean-Claude forgot to (re)build the ZIP:s???
Could be. Just to be sure, I re-generated and uploaded all the last lib versions.

Posted 19/01/2011 14:56:36
apoeschl

Hi,
I also have got issues with the Ether card on the Carrier board. The Ether card itself is doing fine - all HTTP request are answered correctly. But The RF12 communication doesn't work.
I modified the sketch to produce more output and I found out that the length of the RF12 packages received (within the rf12recvDone branch) is zero and I get a CRC of 232. If I disable all the ethernet functions and unplug the Ether card, the system is receiving all the packages correctly (which excludes an error in the RF12 soft- or hardware).
As the problem is just occurring in combination with RF12 AND ethernet, maybe this is an interrupt issue? Any problem with calling rf12recvDone too early?
Regards, Andreas
Edit: I downloaded the latest EtherCard ZIP just some minutes ago - so this shouldn't be an issue.

Posted 19/01/2011 20:44:42
bmj

Hello
Much better. After installing the new ZIP:s receive works if the node in the broadcast is set to 0 (all nodes). I didn't get it to work if the dest. node in the transmission is set to 16 (the EtherNode) but I'm not sure if it should work!?! I have not tested to sniff for node to node communication but I guess those are filtered out by the RF-chip (=wrong node ID)???
jcw: If I remember correctly Subversion can run server-side scripts when some conditions are fulfilled. Maybe it can be used to auto generate the ZIP:s and put them online on eg. branch to stable realise of the code. This would save you some work.

Posted 20/01/2011 12:34:58
jcw

> Subversion can run server-side scripts when some conditions are fulfilled
Ah, good point. I'll look into it.
Although I still think most people would benefit from pulling the code out with SVN. It lets you tweak things while still being able to track changes from JeeLabs...

Posted 20/01/2011 15:24:52

smihai

Hello, have you managed to show on the webpage packets received ?
I am using the folowing code on another jeenode to send data that is to be received by the ethernode:


void setup() {    Serial.begin(57600);    rf12initialize(3, RF12868MHZ, 1); 
}
void loop() {    delay(1000);
    int32t times=0;
    struct { int16t temp;} payload;
    payload.temp=0x63;
    while (!rf12canSend())
    rf12recvDone();
    rf12sendStart(0, &payload, sizeof payload);
    Serial.print("\n sent value= ");    Serial.print(payload.temp,HEX);   
}

p.s. i downloaded all new code from the websites repository

Posted 26/01/2011 11:08:28

smihai

any thoughts onto this? i think i'll try to setup a bare bones webserver that displays the packets from RF but that will take a while to code ;))

Posted 29/01/2011 11:36:08

jcw

I uploaded the EtherNode.pde sketch, and get this:

    RF12 etherNode - 868 MHz, group 5 - configure - send packet
    Last 10 messages:

    0000: OK 38 170 73 226 0
    0001: OK 5 13 79 208 0
    0002: OK 3 185 22 3 0
    0003: OK 38 170 73 226 0
    0004: OK 34 26 81 200 0
    0005: OK 6 169 73 226 0
    0006: OK 3 186 22 3 0
    0007: OK 23 2 91 186 0
    0008: OK 19 17 85 33 103
    0009: OK 19 2 8 225 42 71 14 0 17 0
    Uptime is 00:03:18

So the code seems to be ok. I don't know why you're not getting any data. If you get a web page, then the Ether Card and web server must be working. I'm using the RF12 and EtherCard libs as in subversion and as in the ZIPs.

Posted 29/01/2011 20:03:23

smihai

After working on this issue for a couple of days i firstly identified that the RF library went south when i tried eth.SpiInit and then had a stroke of luck and realized that ... (and you're so gonna "n00b" me for this) i only downloaded the latest EtherCard library and NOT the RF12 which was an older model. After downloading the RF12 and running the demo again it worked like a charm. Thanks for the support JC and i should get my mind around subversion next.

Posted 30/01/2011 07:52:24
jcw
I'm glad you got it working in the end!
The good news is that the generation of the different library ZIPs is now automatic, so they will be up to date after each change in subversion from now on.
Do try subversion though. Once you've got it going, you will never have to download/unpack or replace a directory again. Just "update".
Another way to detect such troubles, is to compare the auto-generated revision code at the top of the source files:
```
    // $Id: RF12.h 6394 2010-12-10 19:25:04Z jcw $
```
These can be compared against the files in subversion, i.e. .
Posted 30/01/2011 10:56:38