AT module and RN2483: not working with my Linux box

[espruino-discuss2]

Posted at 2016-09-29 by GeekBot

Hello,
I am working on a project using a Rn2483. I think the AT module very valuable in this context and I tried to use it. But I experienced huge difficulties to make it working with Rn2483. Sending commands with \r\n at the end, such as ‘sys factoryYRESET\r\n’ are not executed by the radio module. I believe that's a cr/lf problem but I don't manage to master it. I looked at the code of the AT module checking that write statement is used instead of print. The code seems ok, so far I understand it....
I wonder if the fact that my host machine is a Linux box may modify the way the code is minified specially the way Cr/lf is managed. This question comes from a remark in the AT module code: ‘’TODO: something odd about Espruino on linux seems to mean that extra '\n' get inserted */’’. This remarks rings the bell’, but I don't know what is hidden behind it.

Can you please advice on this issue?
Is there anybody who uses RN2483 + AT module?

Thanks a lot.
GeekBot

PS:
Epruino Pico is used on this project.
Not tested on Windows yet.

[gfwilliams]

Posted at 2016-09-29 by @gfwilliams

Are you running Espruino itself on Linux, or are you running it on your Espruino Pico board?

The remark was to do with what happens if you run the Espruino interpreter itself on Linux (eg. Raspberry Pi) - I think in that case it's more to do with Espruino's serial port implementation on Linux. Since you're only using Linux as the machine that talks to the Pico you should be fine (I use Linux for everything and don't have problems).

Can you try at.debug() first? That should give you some debugging information about what's being sent/received.

Also, have you checked that the baud rate/bits/parity is all correct?

[espruino-discuss2]

Posted at 2016-09-30 by GeekBot

Hello Gordon,

Thanks for your answer.
My code runs on Pico, not on Linux, (now I understand the comment in the code).
Baud rate, parity and flow are correct.
I am sure that the RN module works, because I tested it using the Foca adaptor and the GtkTerm with the same Serial parameters as those present in the code. It's the same problem on Serial1 and Serial2.

My test code runing on Pico is this one:

var SERIAL_OPTIONS = {
    "rx":B7,
    "tx": B6,
    "bytesize": 8,
    "parity": null,
    "stopbits": 1,
    "flow": null
};
  
Serial1.setup(57600, SERIAL_OPTIONS);

var at = require("AT").connect(Serial1);

at.debug();

at.cmd("sys reset\r\n", 2000, function cb(d) {
  
  console.log(d);
  
});

When I run it, I get :

echo(0);
["sys reset\r\n"
=undefined
undefined

I should get the reset return message which gives RN2483 version, date...
The RN module is correctly connected and voltage levels are correct on the PINs. I use a breakboard from Dr Azzy.

So my question is: Is the code above correct ? Should it work ?
Thanks a lot.
GeekBot

Just to clarify how to send commands from a Linux GtkTerm to the RN2483 (using Foca adpator):
1/ Uncheck the CRLF option in Gtkterm
2/ You need to add CTRL-M CTRL-J manually to the command (to send the CR LF), then the command get executed correctly on the RN2483.

[gfwilliams]

Posted at 2016-09-30 by @gfwilliams

Yes, what you've got there should work. How about totally stripping it back to basics and seeing if anything happens:

var SERIAL_OPTIONS = {
    "rx":B7,
    "tx": B6,
    "bytesize": 8,
    "parity": null,
    "stopbits": 1,
    "flow": null
};
  
Serial1.setup(57600, SERIAL_OPTIONS);
Serial1.on('data', function(d) {
  console.log(">>"+JSON.stringify(d));
});
Serial1.write("sys reset\r\n");

If that doesn't work then perhaps your wiring is wrong? TX should go to RX and vice versa (and obviously you need GND too).

If it does work, perhaps the module itself doesn't send newlines in the way that the AT library is expecting? In that case it might be that the library isn't detecting a newline, so isn't calling the callback with the data.

[espruino-discuss2]

Posted at 2016-09-30 by GeekBot

Thank you Gordon,
We are sure that there is ground problem or tx/rx confusion. I work with another person and we double check the wiring. We receive the reset message from the module at power on, so it means that at least basic serial parameters look OK.
The snippet you provide above produces nothing back. It seems that the RN module doesn't catch the \r\n. Looking on the line with the Foca converter tx input, we see the string with CR/LF is emitted by Espruino. So it seems clear that the module doesn't interpret the command. What is strange is that the same command issued by the Foca adpator is executed by the module. So the Foca adaptor and Espruino don't behave exactly the same, and can't manage to undestand where they are different.
One way if to check the electrical signals on the line to see if we are exactly at the good speed or if the Espruino or module clocks and serial speed are shifted. But I need a memory oscilloscope for that, and I don't have yet...
Any idea is welcome, we are totally stuck on this issue.
Best regards
GeekBot

[espruino-discuss2]

Posted at 2016-09-30 by DrAzzy

Thanks for using my breakouts :)

Two things I've done:

With digital 'scope, you can crank the scan speed WAY down and try to see if you can catch what it's doing.

Run serial lines to the RX of another adapter to listen to what's being sent. I have a contraption that uses a few '339's, and outputs the TX/RX lines each going into the Rx line of another connected serial adapter, and the Tx lines of those adapters let me inject text into each of the lines I'm probing (though this needs to be used with caution, because the 339 could be fighting an output).

[espruino-discuss2]

Posted at 2016-10-02 by GeekBot

Thank you Dr Azzy, I did your recommendation and found out that it was not a clock problem. Then I focussed on the init procedure of the module and found out that the problem was tricky, due to an involuntary break condition during module power up which puts the module in a locked state. So, I reworked the init procedure carefully to avoid this break condition and now the module works perfect. I also confirm that your breakout is a great device.
GeekBot

[gfwilliams]

Posted at 2016-10-03 by @gfwilliams

Could you post up a bit more information about what caused the problem for you/how you fixed it?

I think others would be interested in this module (in fact I received some for a project just last week) so it'd be a huge help if we share some information on it - in fact it'd be great if you were able to share your code so we could turn it into a module.

[espruino-discuss2]

Posted at 2016-10-03 by @yerpj

FYI, I worked on the RN2483 this week-end, and I finally was able to send some datas on the server. here is the debug script I used, in case you need it:

var rxbuf=[];
var initState=0;
var devAddr="YOUR_DEV_ADDR";
var nwkSKey="YOUR_NETWORK_SESSION_KEY";
var appSKey="YOUR_APPLICATION_SESSION_KEY";
Serial1.setup(57600, { tx:B6, rx:B7 });
Serial1.on('data', function (data){
  if(data.indexOf('\n')>-1)
  {
    console.log(rxbuf);
    if(rxbuf.indexOf("mac_tx_ok")>-1)
      digitalWrite(LED2,1);
    else
      digitalWrite(LED2,0);
    rxbuf=[];
  }
  else
    rxbuf+=data;
});

function loraReset(){Serial1.print("sys reset\r\n");}
function loraGetVer(){Serial1.print("sys get ver\r\n");}
function loraGetVcc(){Serial1.print("sys get vdd\r\n");}
function loraGetHWEUI(){Serial1.print("sys get hweui\r\n");}
function loraSetDevAddr(addr){Serial1.print("mac set devaddr "+addr+"\r\n");}
function loraSetNwkSKey(key){Serial1.print("mac set nwkskey "+key+"\r\n");}
function loraSetAppSKey(key){Serial1.print("mac set appskey "+key+"\r\n");}
function loraSetADR(state){
  var OnOff=( (state=="ON") || (state=="on") || (state=="On") )?"on":"off"; 
  Serial1.print("mac set adr "+OnOff+"\r\n");}
function loraGetDR(){Serial1.print("mac get dr\r\n");}
function loraGetChannel(){Serial1.print("mac get ch\r\n");}
function loraGetBand(){Serial1.print("mac get band\r\n");}
function loraGetRxDelay2(){Serial1.print("mac get rxdelay2\r\n");}
function loraGetpwridx(){Serial1.print("mac get pwridx\r\n");}
function loraJoinABP(){Serial1.print("mac join ABP\r\n");}
function loraGetStatus(){Serial1.print("mac get status\r\n");}
function convertToHex(str) {
    var hex = '';
    for(var i=0;i<str.length;i++) {
        hex += ''+str.charCodeAt(i).toString(16);
    }
    return hex;
}

function loraTRX(data){
  digitalWrite(LED2,0);
  console.log("Sending: "+data);
  Serial1.print("mac tx uncnf 1 "+convertToHex(data)+"\r\n");
  //setTimeout(loraGetStatus,150);
}

function init()
{
  switch(initState)
  {
    case 0:
      console.log("LoRa init begin...");
      console.log("resetting...");
      loraReset();
      initState++;
      break;
    case 1:
      //console.log("\nVersion:");
      //loraGetVer();
      initState++;
      break;
    case 2:
      //console.log("\nVCC:");
      //loraGetVcc();
      initState++;
      break;
    case 3:
      console.log("\nHW EUI:");
      loraGetHWEUI();
      initState++;
      break;
    case 4:
      console.log("\nSetting devAddr");
      loraSetDevAddr(devAddr);
      initState++;
      break;
    case 5:
      console.log("\nSetting nwkSKey");
      loraSetNwkSKey(nwkSKey);
      initState++;
      break;
    case 6:
      console.log("\nSetting appSKey");
      loraSetAppSKey(appSKey);
      initState++;
      break;
    case 7:
      console.log("\nDisabling Adaptative Data Rate");
      loraSetADR("off");
      initState++;
      break;
    case 8:
      //console.log("\nRetrieving data rate...");
      //loraGetDR();
      initState++;
      break;
    case 9:
      //console.log("\nRetrieving channel...");
      //loraGetChannel();
      initState++;
      break;
    case 10:
      //console.log("\nRetrieving band...");
      //loraGetBand();
      initState++;
      break;
    case 11:
      //console.log("\nRetrieving rxDelay2...");
      //loraGetRxDelay2();
      initState++;
      break;
    case 12:
      //console.log("\nRetrieving power output index value...");
      //loraGetpwridx();
      initState++;
      break;
    case 13:
      console.log("\nJoining ABP...");
      loraJoinABP();
      initState++;
      break;
    case 13:
      console.log("\nStatus: ");
      loraGetStatus();
      initState++;
      break;
    case 14: 
      initState=-1;
      break;
    default:break;
  }
  if(initState!=-1)
    setTimeout(init,50);
}

function BTNHandle()
{
 var a=getTime().toString().slice(7,9); 
  loraTRX(a);
}

setTimeout(init,1000);
setWatch(BTNHandle,BTN,{repeat:true,edge:'falling',debounce:50});
save();

[gfwilliams]

Posted at 2016-10-03 by @gfwilliams

Great - thanks! What did you use as the server out of interest?

[espruino-discuss2]

Posted at 2016-10-03 by @yerpj

I tried using The Things Network infrastructure as it becomes popular in Switzerland (thx @GNZ for your efforts)

[espruino-discuss2]

Posted at 2016-10-03 by GeekBot

The problem I had is relative to power up and reset of both Espruino and RN2483. When the Espruino boots, rx and tx lines are set as GPIO and tired down to 0. The RN2483 sees this as a break condition and waits indefinitely for the 0x55 character. You can't escape this state. The only way is to make a hard reset on the module while tx (of Espruino) is set to 1. So the right sequence is:
1/ Power up the system (Espruino and RN2483)
2/ Set Serial configuration (this make the Serial GPIO tx @ 1)
3/ Wait a few hundreds of ms
4/ Do a hard reset of the RN module using one Espruino GPIO line (keeping tx espruino at 1)
5/ Wait 400 ms or catch RN reset message
6/ Go ahead, the system is ready.
HTH
GeekBot

[espruino-discuss2]

Posted at 2016-10-03 by DrAzzy

Huh - so if the problem is the RN2483 seeing a low on it's RX line at start up, a 10k pullup to 3.3v on the RX line might help - the pins should get initialized as high impedance, so a pullup should ensure that they don't start out low...

[espruino-discuss2]

Posted at 2016-10-04 by GeekBot

@drazzy, I discovered the problem looking at signals with my oscilloscope, I am quite sure that my code didn't pull down the line before, but a mistake on my side is always possible... I confess that I am a bug maker... However, if GPIOs are in high impedance state at reset, the oscilloscope can pull the line down by itself since it has a 1 M input impedance only. Anyway, the module was stuck in the break condition. I like the idea of putting a pullup, I will test it. However, when power goes on, I always fear a glitch on the GPIO that could leave the module in the deadlock. Do you think that when power goes up, that GPIO will remain in high impedance? No glitch? I have to look at the ST datasheet...

[gfwilliams]

Posted at 2016-10-04 by @gfwilliams

Great - thanks for the explanation! I probably would have hit that as well :)

[espruino-discuss2]

Posted at 2016-10-04 by @yerpj

Do you think that when power goes up, that GPIO will remain in high impedance? No glitch?

Unfortunately you cannot be sure there won't be any glitch at power-up because of the high impedance. As @drazzy said, only a pullup will give you the guarantee that the TX line of your STM32 is at a known state at power-up.
Another way to avoid any confusion may be to hard reset the RN2483 after having configured the USART interface (pin 32 of RN2483), but then you need an extra wire...

[espruino-discuss2]

Posted at 2016-10-31 by DrAzzy

Thanks a lot for the linking!
Yeah - I'd gotten a lot of requests for it, and decided to just bite the bullet and start offering them. Probably should have sooner.

I'm afraid I haven't added anything like that to the module - I don't really have any projects that call for LoRa communication, so I've played with these boards embarrassingly little myself.

Is there anywhere I should be putting links back to from my RN2483 related pages?

[gfwilliams]

Posted at 2016-10-31 by @gfwilliams

Maybe link to http://www.espruino.com/RN2483 as well? Might be handy for buyers to have example code available :)

@drazzy Feel free to add a link to your new board to there - it'd be really handy to have a link to something 'ready to go'. Also, just IMO, but you could offer an aerial as well. They're pretty cheap, but I had to order mine from China which took ages. I'd definitely have bought an 'all in one' if it were available...

[espruino-discuss2]

Posted at 2016-10-31 by DrAzzy

Great, thanks. I'll order some aerials to offer as addons. Do you have experience with any specific ones that you thought were good?

[gfwilliams]

Posted at 2016-10-31 by @gfwilliams

Honestly, I have no idea. I bought this one, and it seems to work (but I haven't done any distance tests): http://www.ebay.co.uk/itm/291844009518

You can get them a bit cheaper though.

[espruino-discuss2]

Posted at 2016-10-31 by @yerpj

@drazzy from my own experience, for such a device it will be far better to use a dipole antenna. The one pointed by Gordon should be a good candidate.

[espruino-discuss2]

Posted at 2016-10-31 by DrAzzy

Cool, thanks. Ordered a few.

[gfwilliams]

Posted at 2017-02-20 by @gfwilliams

Does anyone have any links to sensible code for a really basic (non-TTN) LoRaWAN setup? I'm trying to get something really simple set up that I would have thought would be easy:

• RN2483 with an Espruino
• ic880a concentrator & Pi
• Sending and receiving packets of data from node.js

After much fighting I now have packet_forwarder running and forwarding packets over UDP, which I can decode in node.js. However it looks like sending data the other way is going to be just as painful, if not more so.

@Jean-Philippe_Rey any ideas? It seemed like you'd done quite a bit of LoRa stuff

[espruino-discuss2]

Posted at 2017-02-20 by OwenBrotherwood

https://github.com/lrnzzz/RN2483-LoRa-Shield is the shield
Some guy sold me a nRF52 device that is neat.
Trying to find some spring loaded connectors or else risk having to buy more devices from a guy if I make mistake with soldering.
Code ?

• hmm, Espruino was my best bet.

https://www.thethingsnetwork.org/community/silkeborg/

@GNZ is zurich the things network

github is a great place to post WIP ...

lrnzzz/RN2483-LoRa-Shield#2 is a request for a puck.js footprint

• in the meantime, I drill in the two boards I have and cross my fingers with the construction process

By the way, things go slow at times cos the kids are building ...

Edit: Probably wrong thread

[gfwilliams]

Posted at 2017-02-21 by @gfwilliams

Did you post in the wrong thread? I know you posted a bunch of stuff in other RN2483 threads, but I'm not convinced this really has much to do with the question of setting up a non-TTN LoraWan network

[espruino-discuss2]

Posted at 2017-02-22 by gnz

Hey @gordon, in general, TTN shouldn't differ much (at all?) from any other LoRaWAN network. I haven't tested myself, but there are a bunch of guys in our local community that have sensors that they interchangeably switch from network to network without issues.

If you wanna setup a local test environment to isolate from TTN and any other provider, I'd recommend this backend: https://github.com/brocaar/loraserver It's well documented and I know others have tried it successfully. About the concentrator, I guess you have it figured it by now, but you could use TTN install scripts (https://github.com/ttn-zh/ic880a-gateway/wiki) and just change the backend server to forward to on the local_conf.json

The biggest problems you will face with downlink (from backend to espruino) are related to time sync, the receive window is rather small, and it's a source of constant issues on some MCUs.

Let me know if I can give you a hand.

Cheers
Gonzalo

EDIT: Actually, I DID test switching networks now that I remember, and it worked without having to make changes to my node. Just provision the keys on the new network and off you go.

[gfwilliams]

Posted at 2017-02-22 by @gfwilliams

Thanks! I'll have a go at setting that up - I'd had a quick go, but it seemed a bit heavyweight with the MQTT transformation in there too.

So far I'd just implemented the packet forwarder protocol in node.js, so I can receive fine - and I can even transmit as of yesterday (but just not it a way that can be received yet - I think I need to get the correct transmission format).

For what I'm doing the LoRa nodes are well powered, so I can increase the receive window if needed. I guess the best thing is to make sure I can get something working with lora-server before I go off trying to do my own thing :)

[espruino-discuss2]

Posted at 2017-02-22 by gnz

before I go off trying to do my own thing

yep, I'd advice against building it yourself unless you have a lot of extra time in your hands. Not sure what's your project exactly, but unless your goal is really to build a packet forwarder in node.js, then go with lora-server (or TTN, or a loriot.io community account) as your backend.

Unless -of course- you're trying to build an espruino-powered lorawan gateway :)

[espruino-discuss2]

Posted at 2017-03-17 by OwenBrotherwood

wonders how far Gordon is with his thing as I just received 3 ic880a (spi) as well as having a couple of RN2483 boards that go in action in a bit.

[gfwilliams]

Posted at 2017-03-20 by @gfwilliams

3 ic880a? Wow, that's expensive!

I haven't had time to work on it sadly, but I'll have to get back to it soon. As @GNZ suggested it looks like I'll have to go with lora-server.

I'm working on smart electricity meters for a solar electricity system in developing countries, and there isn't a reliable internet connection so I need to make sure I can do everything I need to locally.

[espruino-discuss2]

Posted at 2017-03-20 by OwenBrotherwood

Yep: expensive, I got sponsered: they will be used for play and learn in education while the county council tried to find a sponsor for 5 that cover the town. In the meantime, they get setup and get used by kids if I can find the best solution for nodes with play and learn and fresh air measurements.
The lack of internet connections (and power) is actually a small subset of the problems I have ( a luxury problem in europe) in order to allow for quick diagnose of a down gw.

The play and learn pi GW will probably have a https://nodered.org/ server as I might as well put some of the pi to use with that (or any other crazy idea I get).

Edit
Actually, the lack of a stable internet is sometimes a problem in some places in europe for play and learn

EDIT
There are many thoughts about GW and lack of Internet backhaul that I want to address in my solution that may have interest:: new thread??? @gordon