Search results for:

I love ESPRUINO :)

Me too, more people should really be using it 😁. I'm working on a project to showcase at work (WiFi module, not LoRa though), hopefully people will see the opportunities there as well 😏.

@tcpipchip = @user95229

Oh ok, got it 😊.

Cool 😎!

Awesome--I don't know that module though 👌😊.

Until now, I haven't had issues communicating with it using the SX library, and all sources I have seen claims that RA-02 is based on the SX1278 chip (it's hard to confirm anything with these Chinese modules though).

I haven't tried anything else than sending/receiving at different frequencies, so I can't confirm if FSK/OOK, or stuff like spread factor etc. can be configured though.

I'm using the RA-02 myself 😊.

Ah ok, I wasn't sure if you were still in debugging mode. Great to have more Espruino guys using this 👍.

Yes. If you tell me what you're up to, I might be able to provide you with better answers.

AI Thinker Ra-02

The reason I asked is because I had an issue with reading data using the HW SPI.

As suggested by @Gordon, I've tried flashing Espruino 2.06, and an issue seems to have been introduced between Espruino v2.06 and 2.08.

I've attached some screenshots where I use the ESP32-WROVER to read from a chip which is expected to respond with [0, 18]. Be aware that with v. 2.06 SPI1 seems to have been used where we'd use SPI2 today, thats why I'm using it in the examples on v. 2.06.

I post this just for reference, I'll open an GitHub issue.

Quick question; has anyone been able to use SPI2 (hardware SPI) to receive data on the Espressif ESP32-WROVER-B?

Follow up question; which pins did you use?

Thanks 🙂!

OK, I think I got to the heart of the problem, SPI1 is working beautifully (I haven't tested with the SX library and all that, but I get data through MOSI now).

Apparantly capacitors on the AI Thinker ESP32-A1S prevents us from using GPIOs 5, 18, 19 and 23 for SPI (according to this comment (Edit: may be incorrect, the comment is referring to a dev. kit using the same chip)).

Thank you MaBe for your help!

Edit: still having issues, posting a new question 🙂

In any case this is what I see on the SPI lines for HW and SW SPI of this example code (nothing on MOSI):

const PIN_SCK = D18;
const PIN_MISO = D19;
const PIN_MOSI = D23;

// HW SPI
SPI2.setup({ sck: PIN_SCK, miso: PIN_MISO, mosi: PIN_MOSI});
SPI2.write([1,2,3]);

// SW SPI
// const spi = new SPI();
// spi.setup({ sck: PIN_SCK, miso: PIN_MISO, mosi: PIN_MOSI});
// spi.write([1,2,3]);

OK, perhaps I'm on to something (my own mistake 😬).

I'm using a chip called AI Thinker-A1S, which I'm sure I've read somewhere should be compatible with the Espressif ESP32-WROVER (which uses the IOs MaBe mentioned), but I can't find that information now.

Reading the datasheet of the AI Thinker-A1S, it looks like the IOs used for SPI is a little different though; MISO is IO21 and not IO19 (although they use a terminology like VSPIIDHS1STROBE instead of VSPID as the WROVER does).

Is there anything I can do to make HW SPI work on this device?

So to be completely clear, this is what's not working for me 🙂:

const PIN_SCK = D18;
const PIN_MISO = D19;
const PIN_MOSI = D23;
const PIN_CS = D5;        // NSS
const PIN_RESET = D21;

// Configuration
const txConfig = {
    bandwidth: 0,
    freq: 434330000,
    power: 17,
    forcePaBoost: true,
};

// HW SPI (replace the three lines above)
SPI2.setup({ sck: PIN_SCK, miso: PIN_MISO, mosi: PIN_MOSI });
const sx = require("SX127x").connect({ spi: SPI2, cs: PIN_CS, rst: PIN_RESET });

// Poll DIO0 for interrupts
setInterval(function () { sx.onIRQ(); }, 100);
sx.setTxConfig(txConfig);

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

(Edit: Perhaps I should try to remove the SX127x stuff, and boil it down to only using the SPI, I'll be back.)

Sorry, the example was not clear enough 🙂. I just made an example where I could easily switch between using SW spi (the stuff with ".. new SPI ()... "), and HW SPI (the one with "SPI2 ... ") for this demonstration.

The problem occurs when I try to use the HW spi (the block I commented out in the example of #8).

Yes, setting the baud rate was what started this endeavour in the very first rate--but first I need HW SPI to work though 🙂.

OK, so I've replaced the pins with the ones you mention--but still struggle a little 🙂!

Setup now looks like this (only the pins has changed):

const PIN_SCK = D18;
const PIN_MISO = D19;
const PIN_MOSI = D23;
const PIN_CS = D5;        // NSS
const PIN_RESET = D21;

// Configuration
const txConfig = {
    bandwidth: 0,
    freq: 434330000,
    power: 17,
    forcePaBoost: true,
};

And the code like this:

// Setup
const spi = new SPI();
spi.setup({ sck: PIN_SCK, miso: PIN_MISO, mosi: PIN_MOSI });
const sx = require("SX127x").connect({ spi: spi, cs: PIN_CS, rst: PIN_RESET });

// HW SPI (replace the three lines above)
// SPI2.setup({ sck: PIN_SCK, miso: PIN_MISO, mosi: PIN_MOSI });
// const sx = require("SX127x").connect({ spi: SPI2, cs: PIN_CS, rst: PIN_RESET });

// Poll DIO0 for interrupts
setInterval(function () { sx.onIRQ(); }, 100);
sx.setTxConfig(txConfig);

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

I've attached two screenshots of the SCK, MOSI and MISO, and it looks like nothing is happening on the MOSI line when using HW SPI with this example--I'm sure I just missed something obvious, I hope someone can spot it 😬🙌?

(are there restrictions to the CS/RESET pins as well perhaps? Do I need to set the I/O "mode" for some of the pins manually? Do I need to specify more parameters when using HW- as opposed to SW SPI?)

to be honest, it took me several hours to figure this out, when I tried to use it the first time ;-)

Glad to know I'm not alone 😁

Which hardware are you using to captured the radio outputs?

I'm using the HackRF One I bought a few years back, it's been priceless! When a signal is not received, it's invaluable to know that the transmitter at least tries to do something--that's a good half of the setup I don't have to debug right there ⭐⭐⭐.

Great, I'll try that out 🙂! I did think about that many, many, many, times, but I just could not track down the information, where did you find it?

Hey 👋,

I'm playing around with the SX127x library in a large project, and have some problems using the HW SPI with the SX127x module.

I've boiled an example down based on the example code.

This works (soft SPI):

// Pins
const PIN_SCK = D5;
const PIN_MISO = D18;
const PIN_MOSI = D23;
const PIN_CS = D19;                               // NSS
const PIN_RESET = D21;

// Configuration
const txConfig = {
    bandwidth: 0,
    freq: 434330000,
    power: 17,
    forcePaBoost: true,
};

// Setup
const spi = new SPI();
spi.setup({ sck: PIN_SCK, miso: PIN_MISO, mosi: PIN_MOSI });
var sx = require("SX127x").connect({ spi: spi, cs: PIN_CS, rst: PIN_RESET });

// Poll DIO0 for interrupts
setInterval(function () { sx.onIRQ(); }, 100);

sx.setTxConfig(txConfig);

// This one uses an interval, to show that it works continuously
setInterval(() => {
  sx.send("Hello", function () {
      console.log("TX done");
  });
}, 500);

But this doesn't (HW SPI, same txConfig, same pins):

// Setup
SPI1.setup({ sck: PIN_SCK, miso: PIN_MISO, mosi: PIN_MOSI });
var sx = require("SX127x").connect({ spi: SPI1, cs: PIN_CS, rst: PIN_RESET });

// Poll DIO0 for interrupts
setInterval(function () { sx.onIRQ(); }, 100);

sx.setTxConfig(txConfig);

// This one is just "locked" in a state of constant transmission (see screen capture)
sx.send("Hello", function () {
    console.log("TX done");
});

My LoRa module is the AI Thinker RA-02.

Anyone have an idea as to why 🙂?

I've attached examples of the captured radio outputs, but I think I've boiled it down to the HW SPI being off in some way, and not setting the radio up properly to begin with.

Yeah, the outlier being specifically "0b ..." definitely added to the confusion ☺️.

Hi Gordon,

Ok perfect 👌! Yeah, that seems extremely unlikely 🙂. Four boards so far, 2 x having only numbers, and 2 x numbers and a single 'b' at the same position 🤯.

Thanks!

/rj

Hey 👋!

I was trying to use the getSerial()-function on a bunch of custom boards, but was puzzled when I got results like "29005900-0b513934-38363235" (note the "b")

The documentation states: "Returns The board's serial number", and based on the responses I got on some official Espruino Picos ("40005900-04513432-33343134" and "33006900-04513432-33343134") I guessed it was just a string containing base 10 numbers. But now I'm not so sure what to expect.

These are custom boards with STM32F401CEU6 running Espruino Pico firmware v. 2.08.

Any idea what could be going on here?

Hey 🙂,

I'm working with the ESP32 in an application where I have to switch between being in AP mode, and connect to my home WiFi.

Problem:
I need to send a list of available access points created using the wifi.scan()-function, but sometimes an old scan seems to "hang" and I get the error: A scan is already in progress. forever.

I found the place in the source code, that generates the error: jswrap_wifi_scan.

Something strikes me as odd though;
the variable for the callback function g_jsScanCallback is assigned in the beginning of that function, and released again in the end of a function called scanCB. But I see multiple return statements in jswrap_wifi_scan in case of different errors, so couldn't it be that the variable is assigned, but the scan never kicked off 🤔. It would never get cleared again.
I'll admit, I can't figure out how the event that calls scanCB is finally kicked off, but g_jsScanCallback is assigned in line 894, and jswrap_wifi_scan could be exited only a few lines below at line 906, and I don't see the scan getting started anywhere in between.

Observations:
... in any case, the problem is a bit hard to re-produce, but this is roughly what I observe:

1. If I completely shut power off the board, and re-connect it, I'm allowed to scan. And successsfully perform scans after that. Starting an AP, and still perform scans after that.
   
2. However, if I've had a failed attempt on connecting to wifi using bad credentials with the wifi.connect-function, I get the scan error the next time I try to scan, and now it seems to hang forever
   
3. If I flash my code onto the board again, and wait for onInit to run, the scan still fails
   

4. I have always gotten these two errors when I connect the board, but haven't given them much thought until now:

   WARNING: Scan stop failed
   WARNING: set rssi scan not implemeted yet
   Running onInit()...
   

Thoughts?

It's a bit of a hack but it's possible

I'll take it--thanks 😎!

Yeah, this is what someone suggested on SO as well.

If I've understood correctly, callbacks seem to be the general convention used across the project, so I think it would be more correct to have connect provide a callback-function with an error object/string, but perhaps I'm missing something 🙂.

I'll leave messing with the modules to the pros 😊.