Search results for:

@DrAzzy Thx for the link! I was looking for such an assembled board. They seem to be rare up to now... The link is now part of the guide.
The current module is kind of minimalist. Based on people inputs, it should:

• implement OTAA authentication
  
• provide a bandwidth-efficient way of detecting a valid link (mac set linkchk ?!?)
  
• provide a convenient method to poll the RX mailbox
  
  

If you have already done such things, it could be very helpful to share your work.
Anyway I will probably do it by myself too, just for my curiosity ;-)

Doesn't matter how. If you consider the content of this guide could be helpful for the Espruino community, feel free to extract what you want from it. Or I can make a PR when finished.
Anyway, I would wait until it is completed. Otherwise it will be complicated to update both sources.

@Ollie At MAC level, there is a command that will help you check if you are linked to a gateway, called "LinkCheck ":
This command sets the time interval for the link check prococess to be triggered periodically (Microchip RN2483 Command Reference user's Guide, sectioin 2.4.8.12)
I will try this command, and add it to the JS module if that makes sense.

'HERE' need prefixing with http:// by the look of it?

Done

Also, you could link to the module page on espruino.com? rather than directly to GitHub now.
Done
If you text-search for '###' there's a heading that I thing doesn't have a newline before it so it's getting copied verbatim into the HTML.

I suppose it's OK now.

Would you be willing to copy the bottom part onto a espruino.com TheThingsNetwork page as well? It could be really handy, or I guess at the least I could link to yours from RN2483

Is there any The Things Network related page on Espruino.com?

How do you know if you are in range of gateway? Can you ping them or something

Actually I don't have a deep knowledge about LoRaWAN, I don't think there is any way of "pingping" a gateway.. Maybe @gnz may have the answer?
Anyway I will ask on TTN Slack channel

A guy from TTN (Fokke Zandbergen) asked me to write a quickstart guide on using Espruino+RN2483 with The Things Network. As I already played a little with that, I was able to start writting some line on it.
It is currently being edited and will not be finalized before a few weeks.
In the meantime, if anyone would like to contribute (Add some knowledge, correct the language, or even layout), please do not hesitate.
it is currently hosted on my git. When good enough, it will be transferred on the TTN repository.

I cannot give you an answer but I can maybe give you a workaround. Instead of using onInit(), maybe try to make your own init function, with some delay before execution:

function myInit()
{
  //cut-paste here the content of onInit()
}

setTimeout(myInit,500);

Without knowing exactly why, with this trick, I was able to let most of my scripts work even when invoked from flash. FYI, I had the same behaviour with some I2C displays .

The tutorial made by @gnz on how to build a LoRaWAN-TTN gateway in a week-end could be helpful.
Talking about the RN2483 JS module, I will try to add some additional features such as the ADR (adaptative data rate) configuration, which seems to be supported with TTN. For generic LoRaWAN infrastructures, any input on what is actually needed within the module is welcome.

The module could now be used to connect to TTN, see PR here I just tested it and It works like a charm. You just have to configure the keys then send anything you want:

lora.LoRaWAN(devAddr,nwkSKey,appSKey,function(x){console.log(x);});
lora.loraTX("Hello");

I was quite sure the latest release was 1v88 and I did not even had a look at the revision on my Pico because It knew it was running the latest release ...

I just had a try with the latest binary (1v87.840) and it works well :-). Tomorrow I will certainly have some time to add functions to connect to TTN.

I tried to play with the new RN2483 module. I started by calling the lora.getStatus() in order to verify everything is OK with the communication between the module and the Pico.
Unfortunately I got an unexpected status:

{
  "EUI": "0004A30B00AAAAAA",
  "VDD": 0.004,
  "appEUI": "0004A30B00AAAAAA",
  "devEUI": "0004A30B00AAAAAA",
  "band": "0004A30B00AAAAAA",
  "dataRate": "0004A30B00AAAAAA",
  "rxDelay1": "0004A30B00AAAAAA",
  "rxDelay2": "0004A30B00AAAAAA"
 }

Is the Promise sequence correctly implemented?

Awesome work!
Using the AT library +Promises is the way to go even if it is relatively new.

@gnz It works because it is 99% based on your code ;-)

I totally agree with both of you that it could be a great opportunity for the emerging TTN community to have access to a real module.

Unfortunately I am not comfortable enough with JS to create a module by myself. Instead, I would love to contribute and fill the gaps if anyone could create the module skeleton.

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...

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

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();

It was also my assumption.
I already compared this sensor on my 3 Picos, I got a dispersion of +- 2 degrees, which is quite good for most of applications.

I propose to keep this conversation opened in case of someone would notice problems with the offset of the internal temperature sensor.

Since 1v48, we can call E.getTemperature() in order to retrieve the chip internal temperature. I just read from the datasheet

the internal temperature sensor is mainly suitable for applications that detect temperature
changes instead of absolute temperatures. If an accurate temperature reading is needed,
then an external temperature sensor part should be used. ```
As well as in the reference manual: 

The temperature sensor output voltage changes linearly with temperature. The offset of this
linear function depends on each chip due to process variation (up to 45 °C from one chip to
another).```

I actually never tried to quantify the real accuracy of this sensor. Does anyone have any idea on the actual accuracy ? Does anyone already used an Espruino that has a temperature offset around 45°C ?

The PCB material (most of the time FR-4) has its influence in term of RF performance, as its dielectric constant is not the same as air. Anyway, in your case, you should not worry about radiation pattern, as the module is meant to be put on a breadboard, which contains several metallic strips inside, which will cause most of the radiation loss.
In term of RF performance, a good practice would be to add a small coaxial connector such as U.FL from Hirose (https://en.wikipedia.org/wiki/File:2_mm_SMD_UFL_Socket.jpg), thus allowing the use of an external antenna.
That said, for indoor Wifi, it seems that there is not so many guys complaining about any poor RF performance of a PCB trace antenna on ESP modules.

:-)

As part of an old project, I had to drive an e-paper display [almost the same as yours] on a coin cell battery (CR2032). It was observed that for such a refresh time (each 5 minutes or less) , we got very good results (weeks of life-time) by just having bulk capacitors (low ESR) in parallel with the coin cell and by minimizing the decoupling capacitors dedicated to COG (chip on glass). The trade-off was a slightly longer refresh time (2 seconds instead of 1.0-1.5 seconds) but this was not a problem if the e-paper got refreshed each 3 minutes. This is due to the fact that each time you want to refresh the e-paper, you must first charge the decoupling capacitors of the COG, which can represent a great slice of the lost energy in the drive-circuit.

Is that "dot" a clone of Puck.js? http://doteverything.co/

I also found a tool from Texas Instruments, helping to generate composite descriptors as well as corresponding .INF files. Unfortunately, this tool is focused on MSP430, but the generated descriptors are written as C structures, so they may be of any help for comparing with current descriptors for CDC-HID in Espruino.

I just found a working example of dual CDC (2 COM ports) on a stm32F103 HERE. This example may help.

It seems that on Windows, if there is more than one interface descriptor within a configuration descriptor, the latter should include a IAD (Interface Association Descriptor).

[Device Descriptor]
[ConfigDescriptor]
[Interface Association Descriptor]
[Interface Descriptor] (1)
[EndPoints Descriptors and so on..]
[Interface Descriptor] (2) 
[EndPoints Descriptors and so on..]   

I don't see any IAD in usbd_cdc_hid.c. Maybe this could do the trick in order to allow windows to enumerate this CDC-HID config.

That said, I don't know if IAD are recognized in Linux and macOS

I am exploring USB enumeration with STM32F4DISCO. I will give feedback here in case of positive results.