Search results for:

@gniezen on github

It showing up for me now in the search function as well, thanks for checking!

I want to do that, but need to find the time to separate out the LoRa code into its own module. I also wrote a CayenneLPP encoder that I'd like to contribute as well, but again need to find the time to actually put it into a module.

I contributed a module for the MAX1704x Battery Fuel Gauge a while ago, but I'm not seeing it when I use the search function on the Espruino website?

I originally used the RN2483 module, but when that became unobtainium I switched to the LoRa-E5 (now called Wio-E5) module from Seeed. It has a STM32WL SoC, which contains both an ARM Cortex M4 and a SX126x LoRa radio. The ARM Cortex M4 runs the LoRaWAN stack, and uses an AT command set.

Thanks, I've now updated the link!

Hi all,

I've been working on an open-source outdoor air quality monitor using Espruino for a while now, and it's finally at a stage where I feel comfortable sharing it with you folks! The first batch of ten prototypes used MDBT42Q modules I bought from Gordon, but I found them really hard to solder (even when using a hotplate), so I've since switched to using the E73-2G4M04S1B, which is a bit larger.

Details about the project and build instructions is over on https://www.hackster.io/gerrit-niezen/openairmonitor-494b2c

If you'd like to know more about the story behind the project, have a look at my blog: https://gerritniezen.com/designing-an-open-source-air-quality-monitor-and-building-a-community-sensor

Please let me know if there's anything else you'd like to know, and if you'd like to be a beta tester.

Cheers,
Gerrit

OK, I think I figured it out. I'm using pins D9 & D10 to talk to a I2C device, and according to this thread I needed to disable NFC first. Now it appears to work just fine, and I can even retrieve values from the I2C device (an SHT40 temperature/humidity sensor for which I wrote an Espruino library)

I would still like to know what the best way is to solder these modules? My steps are as follows:

1. Tape the module to the PCB
   
2. Add lots of flux
   
3. Put some solder on soldering iron and drag it across the pins
   
4. Continue doing this until it looks like all connections have been made
   
5. Use solder wick to clean up any bridges
   
6. Clean up the flux with some IPA
   
   

I skipped step 6 last night and this morning my second board stopped working. After cleaning the board it works again, which made me realise that my water-soluble flux is not no-clean flux and should be cleaned.

If I reset the module (pressing button for 5 seconds on startup) I can connect to the board again, but trying to upload a program to RAM or flash causes the same issue again.

Hi there!

I bought 10 pre-flashed MDBT42Q modules to solder onto my own boards that I designed. I've hand-soldered two of them, but can't connect to them reliably over BLE. I can only see the first board's module every now and again when I scan for it from the Espruino Web IDE, and it fails to connect to it. I'm suspecting it could be an issue with the soldering - is there a guide somewhere on how to properly hand-solder these modules?

With the second board I can at least see it every time I scan for it (which is why I'm suspecting bad soldering with the first board), but it's still not connecting reliably. Here is the output from the console log:

>>> Connecting...
Set Slow Write = true
BT> Pre-paired Web Bluetooth device already found
>>> Connecting to MDBT42Q 5ebb
BT>  Device Name:       MDBT42Q 5ebb
BT>  Device ID:         uqDPqM8TCHh0fht7a3w0tg==
>>> Connected to BLE
BT> Connected
>>> Configuring BLE...
BT> Got service
>>> Configuring BLE....
BT> RX characteristic:{}
>>> Configuring BLE....
>>> Configuring BLE.....
BT> TX characteristic:{}
>>> Configuring BLE.....
Set Slow Write = false
>>> BLE configured. Receiving data...
Connected {portName: "MDBT42Q 5ebb"}
Got ""
No Prompt found, got undefined - issuing Ctrl-C to try and break out
Splitting for Ctrl-C, delay 250
Still no prompt - issuing another Ctrl-C
Splitting for Ctrl-C, delay 250
>>> Sending...
---> "\u0010print(\"<\",\"<<\",JSON.stringify(process.env),\">>\",\">\")\n"
>>> Sent
>>> Receiving...
No result found for "process.env" - just got ""
>>> 
[notify_error] Unable to retrieve board information.
Connection Error?
Device found {"portName":"MDBT42Q 5ebb"}
[success] Connected to MDBT42Q 5ebb (No response from board)
>>> Connected to MDBT42Q 5ebb (No response from board)

Any ideas on how can I debug this further?

@fanoush Converting the full hex file to UF2 and just copying that over to the board was very easy and appears to be working, thanks so much!

I was hoping to be able to use the nRF52840 port on the Adafruit nRF52840 Feather (that uses the MDBT50Q module). I managed to successfully compile the .hex file using the attached board file that I based on a combination of the NRF52840DK.py and MDBT42Q.py files.

I don't have the tiny SWD cable on hand, so I was hoping to just use Adafruit's bootloader. I generated a DFU package using

adafruit-nrfutil dfu genpkg --dev-type 0x0052 --application espruino_2v09.134_nrf52840.hex dfu-package.zip

and then successfully flashed it using

adafruit-nrfutil --verbose dfu serial --package dfu-package.zip --port /dev/ttyACM0 -b 115200 --singlebank

Unfortunately I can't connect to the board over BLE afterwards, and it also doesn't mount over USB. Any chance that this could work, or should I just bite the bullet and get a J-Link with the right cable?

Thanks Gordon! I'll put SWD pins on my PCB, but will be ordering the modules from you in the near future.

I've designed a PCB that uses the MDBT42Q module and want to do a small production run of 10 boards. I wanted to support Gordon by buying the MDBT42Q modules directly from the Espruino shop, but it seems that there's only 1 available?

I see I can also buy them from Verical, but how would I flash the Espruino firmware myself? Would I need to use SWD pins on my PCB, or is there a programming jig like with the Puck.js?

Never mind, I just found the "Download from RAM" option under "Access files in device's storage" 😅️

I didn't realise that the Espruino IDE (Chrome Web Store version) doesn't give a warning when you exit without saving, and now my code only exists in my Pixl.js's RAM (as I did not save it to flash). Is there any way to recover it, or should I just start from scratch?

@allObjects Sorry if I wasn't clear. Gordon implemented a simple callback fix two weeks ago (see https://github.com/espruino/EspruinoDocs/commit/8ca56d2929298152f683e4309bf876e735034216#diff-71fd1b58c3b419a0205973a478fd66da5ff6b2c138a5e4a35cfbbb2e129c06b0 ) after our initial discussion earlier in this thread, but I only noticed it after I created my own fix using Promises when I was looking to contribute it back to the code base. I was just wondering when his fix would be published to .../modules.

@Gordon I just spent three hours rewriting the SX127x module to use Promises, got it working, and when I wanted to create a PR I discovered that you already fixed it by adding the callback code 😂️

Callback code works fine 👍️

How does it usually take before the changes on master are available for use?

Hmm, that makes sense but it didn't resolve it either. I tried increasing the timeout from 10 to 100ms, and putting the onIRQ setInterval inside the timeout function, but no luck so far.

Why does the following code work just fine on the Pixl.js when code is uploaded to RAM, but when I use "Save on Send (to Flash)", or save() it wrapped in an onInit() function, does it just print "Sending.." and then stop?

SPI1.setup({ sck:D3, miso:D4, mosi:D5 });
var sx = require("SX127x").connect({spi: SPI1, cs: D6, rst : D7 });

var config = {
  forcePaBoost: true,
};
clearInterval();
// Until DIO0 line irqs are implemented we need this:
setInterval(function() { sx.onIRQ(); }, 100);

sx.setTxConfig(config);

console.log('Sending..');
sx.send("Hello", function() {
  console.log("TX done");
});

I just got LoRa comms working between a Pixl.js (connected to a RFM95W module) and a TTGO ESP32 LoRA board using the SX127x module!

Now I'm wondering how difficult it would be to add a LoRaWAN stack. It appears these are two actively developed stacks that could be ported:

• https://github.com/mcci-catena/arduino-lmic
  
• https://github.com/LacunaSpace/basicmac
  
  

I imagine that should be easier than writing a JS LoRaWAN stack from scratch?

Then there are the new STM32WL chips that have an integrated SX126x radio. So now I'm also wondering how difficult it would be to port Espruino to the NUCLEO-WL55JC dev board and get LoRa working on there?

Thanks so much for the code example! I spent most of Friday evening trying to get this to work, but still no dice. I hooked it up to the logic analyser again, and noticed that the timings on the Pico are not as accurate as what I originally though, but it still works, even though similar timings on the Pixl.js are not working.

Would it at all be possible for you to try and reproduce the issue with Pixl.js and the remote control sockets, just so that we know I didn't make a mistake somewhere else?

Hi @Gordon! Did you manage to look into this issue more at all? I know you were working on https://github.com/espruino/Espruino/issues/1749, but that didn't seem to resolve it.

If this is not fixable in the near future, how would I go about using SPI to do it? Would I just set up hardware SPI and write it out on the MOSI pin?

Gave it a try, but the Pixl.js pulse train is still 29.7ms.

Using a logic analyser, the Pico pulse trains are 27.4ms long, pretty close to the 25 * 1.1ms = 27.5ms:

The Pixl.js pulse trains are 29.7ms long:

I used the remote control example code for both, just changing from A6 on the Pico to D13 on the Pixl.js, and modifying the pulse train sequences for my sockets.

I was on 2v06, so just updated to 2v07 to be sure. No difference.

I'm using the code from the example, but found that I had a little bit more success on Pixl.js by changing

digitalPulse(TX,1,0.9);
digitalPulse(TX,0,0.3);

to

digitalPulse(TX, 1, [0.9, 0.3]);

I was also able to increase the chances of success by sending 40 times instead of 10 times, and it works better for some pulse trains than others (in my case, using button 2 's pulses instead of button 1).

All this led me to believe that it may be jitter due to the RTC. I will try to hook up my logic analyser to see if it is indeed the actual waveforms getting messed up.

• Would the digitalPulse(TX,1,0.001) at the end of the pulse train be affected by the RTC?
  
• Also, does it matter whether I use an analog pin vs a digital pin?
  

I started off using remote control sockets on an Espruino Pico, which worked great. I then switched to a Pixl.js, and suddenly things were not so great. Sometimes it works, and sometimes it doesn't.

I've traced it to this issue, which explains that the NRF52 does not have the same accurate timing as the STM32.

Now I'm wondering if there's another way to send the right pulse stream to the 433.92MHz transmitter, or at least get my new remote control sockets working reliably with the Pixl.js?