search

meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
3.26k stars 787 forks source link

It is highly recommended that the firmware can support esp32 + LORA sx1278, and other meanings #84

Closed MGJ520 closed 4 years ago

MGJ520 commented 4 years ago

To be honest, I highly recommend this function that can support modularity. For example, if you only need SMS, then the interface reminds you that you can only use this, and I hope that the APP of this software can be modified, like the chat room, let The interface is better-looking, and can have the same interface as ordinary mobile phone text messages. It can also support the switch between Bluetooth and WIFI connection instead of flashing the firmware through the computer, because it is too troublesome. Secondly, such a Mesh device hopes to pass WIFI. Support multi-person connection, and multiple people share one device.

I highly recommend that it can be used to support more boards, so that it can pass through different boards and different loRa boards, so that it is easier to DIY! For example, this esp32 Espressif and sx1278 (An Xinxin Ra02)

I really hope that everyone can adopt it and act! At the same time, I also hope it will succeed

From a radio enthusiast

MGJ520 commented 4 years ago

I am your fan, I believe in you!

MGJ520 commented 4 years ago

For convenience, I hope to provide binary files on github.

MGJ520 commented 4 years ago

No one there?

geeksville commented 4 years ago

Hi, alas, I was sleeping ;-)

re: software update over bluetooth This is already implemented, I just have it turned off right now in the app (during alpha)

re: more boards I totally agree. Most boards are easy to port to, though we don't yet have a sx1278 driver (any pull requests would be appreciated). In particular there is an exciting new board this project will support in a few weeks.

Dafeman commented 4 years ago

In particular there is an exciting new board this project will support in a few weeks.

Do spill the beans please!

rradar commented 4 years ago

@geeksville wrote:

re: more boards I totally agree. Most boards are easy to port to, though we don't yet have a sx1278 driver

I did a little search around and found this two very promising libraries:

I'm really looking forward to get this supported. The price for a meshtastic compatible device will drop to $10 :exclamation: once this is supported :rocket:

For example some prices from the country of origin:

a OLED Display will add another ~$2

geeksville commented 4 years ago

@rradar thank you for your note. Since this bug was originally opened we switched to using radiolib so using any radio chipset should now be easy. Currently implemented is sx126x and sx127x.

geeksville commented 4 years ago

@MGJ520 Hi Mango - btw - sx1278 would now be super easy to add. alas, I personally don't have a board with that hardware.

rradar commented 4 years ago

Currently implemented is sx126x and sx127x.

I just downloaded the firmwares and there is no "generic" one for sx126x or sx127x. Would it be possible to provide bin files for these?

sx1278 would now be super easy to add. alas, I personally don't have a board with that hardware.

I would be more than happy to test any alpha/beta/gamma-firmware with my ra-02 lora modules and esp32. Also I have oleds and one gps module to make the most out of it :smiley: Sadly I'm no help with programming or building the firmware itself because I lack the skills for it :grimacing:

geeksville commented 4 years ago

Alas. There is no way to provide prebuilt binaries for generic "this radio chip + this esp32" because the connection choices for SPI signals are completely unspecified.

So unfortunately you'd need to build from source after editing configuration.h. Or (in theory) you could just copy the gpio selections for one of existing supported devices and it should then work with that binary. (We probe at runtime for things like screens, GPSes and radios)

rradar commented 4 years ago

So unfortunately you'd need to build from source after editing configuration.h. Or (in theory) you could just copy the gpio selections for one of existing supported devices and it should then work with that binary.

I found this short instruction here and cloned already the github repo but I'm a little lost already with the first setting for the frequency. I would need to set EU/433 for the SX1278 (RA-02 Modules) I have but I don't to what value to add in this line:

; HW_VERSION (default US)

The first thing I would try (once I have the right setting for the frequency) would be to build a esp32 with my lora module (SX1278) with the same gpio setup as the supported heltec board and try to use the existing heltec profile. Maybe this could work out :smiley:

rradar commented 4 years ago

OK, I'm all set. I have exactly the same gpio connections between esp32 and the ra-02 lora module (sx1278) despite having gpio 18 connected because the ra-02 module is missing a cs pin.

I didn't set the right frequency yet for my lora board (433mhz), but at least I where able to flash something on the board. The log output on the serial I get is this:

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac
geeksville commented 4 years ago

That looks correct, have you tried seeing if it is then printing out serial messages at 921600 baud (not 115200)?

(Sent from a phone - please ignore typos)

On Sun, Jun 7, 2020, 14:51 rradar notifications@github.com wrote:

OK, I'm all set. I have exactly the same gpio connections between esp32 and the ra-02 lora module (sx1278) despite having gpio 18 connected because the ra-02 module is missing a cs pin.

I didn't set the right frequency yet for my lora board (433mhz), but at least I where able to flash something on the board. The log output on the serial I get is this:

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:1044 load:0x40078000,len:8896 load:0x40080400,len:5828 entry 0x400806ac

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/meshtastic/Meshtastic-device/issues/84#issuecomment-640285253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXB2KDG5WR7ERGFGTCTMDRVQDXZANCNFSM4MDXSF6Q .

rradar commented 4 years ago

have you tried seeing if it is then printing out serial messages at 921600 baud (not 115200)?

This was the missing piece, here is the full serial I get:

Emitting reboot packet for serial shell
��Hbooted, wake cause 0 (boot count 1), reset_reason=reset
No I2C devices found
Meshtastic swver=unset, hwver=unset
Setting random seed 1359630630
Read RTC time as 4 (cur millis 96) valid=0
ERROR: No UBLOX GPS found, hoping that NEMA might work
RadioConfig reset!
Installing AES128 key!
Loading saved preferences
Warn: devicestate is old, discarding
Installing AES128 key!
NODENUM=0xfc, dbsize=1
Starting meshradio init...
Set radio: name=Default, config=3, ch=6, power=23
LORA init result -2
NOTE! Recording critical error 3, address=0
sending owner !240ac49bbafc/Unknown bafc/?00
Update DB node 0xfc, rx_time=0
old user !240ac49bbafc/Unknown bafc/?00
updating changed=0 user !240ac49bbafc/Unknown bafc/?00
Adding packet record for fr=0xfc,to=0xff,id=216
Dropping packet - no interfaces - fr=0xfc,to=0xff,id=216
pressing
Trigger powerFSM 1
                  Transition powerFSM transition=boot timeout, from=BOOT to=ON
                                                                              Setting bluetooth enable=1
Pre BT: 187924 heap size
                        Starting bluetooth
*** Mesh service:
geeksville commented 4 years ago

@rradar It looks like you are almost there. I'd say the next step is to figure out which signal is the chip select signal for your sx1278 board. All 1278s have it - though perhaps by a different name. It is chip select, and I bet that's why the lora init fails with error code -2. Good luck!

rradar commented 4 years ago

So the chip is labled:

RA-02 AI Thinker, ISM: 410-525MHz, PA: +18dBm, LORA/FSK00K LoRa-02, SX1278, 433MHz

This looks like the corresponding product specification. More Resources can be found on the AI Tthinker wiki but it looks to me that there is no more technical data sheet available for the RA-02

I now changed the line ; HW_VERSION (default US) in platformio.ini to HW_VERSION=EU and get this serial output:

Connected.
LORA init result -2
NOTE! Recording critical error 3, address=0
sending owner !240ac49bbafc/Unknown bafc/?00
Update DB node 0xfc, rx_time=0
old user !240ac49bbafc/Unknown bafc/?00
updating changed=0 user !240ac49bbafc/Unknown bafc/?00
Adding packet record for fr=0xfc,to=0xff,id=250
Dropping packet - no interfaces - fr=0xfc,to=0xff,id=250
pressing
Trigger powerFSM 1
                  Transition powerFSM transition=boot timeout, from=BOOT to=ON
                                                                              Setting bluetooth enable=1
Pre BT: 187928 heap size
                        Starting bluetooth
*** Mesh service:

but as I understand now I'm still one step before choosing the right frequency...

rradar commented 4 years ago

Wait :hand: @geeksville could my NSS pin be the chip select pin?

image

I guess it could :tada:

Here is my serial output with NSS connected to pin 18 of the esp32:

Connected.
pressing
Trigger powerFSM 1
                  Starting low level send from=0xfc, to=0xff, id=28, want_ack=0
Transition powerFSM transition=boot timeout, from=BOOT to=ON
                                                            Setting bluetooth enable=1
Pre BT: 187876 heap size
                        Starting bluetooth
*** Mesh service:
Completed sending to=0xff, id=28
Dafeman commented 4 years ago

Yep, SS - Slave Select is the same as CS - Chip Select. Looks like you have the correct SPI connection to the Ra-02 now.

rradar commented 4 years ago

Little update.

I have a Lolin32 working with the RA-02 module now. I set HW_VERSION=EU433 in the platformio.ini.

I build another pair of a Lolin32 Lite and a RA-02 module but can't get this flashed. I have the following output in the pio console after the succesful building the firmware (using heltec):

CURRENT: upload_protocol = esptool
Warning! Please install `99-platformio-udev.rules`. 
Looking for upload port...
Mode details: https://docs.platformio.org/en/latest/faq.html#platformio-udev-rules

Auto-detected: /dev/ttyUSB0
Uploading .pio/build/heltec/firmware.bin
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting......
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 3c:71:bf:03:48:18
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...

A fatal error occurred: Invalid head of packet (0xE0)
*** [upload] Error 2
================================================================= [FAILED] Took 21.23 seconds =================================================================

I checked twice with the board if it's working and flashed another firmware and also did a flash_erase. Error stays the same.

Any ideas?

geeksville commented 4 years ago

It might be that board has a serial to USB part that can't run at 921600. Try changing the upload speed in platformio.ini to 115200.

(Sent from a phone - please ignore typos)

On Mon, Jun 8, 2020, 03:50 rradar notifications@github.com wrote:

Little update.

I have a Lolin32 working with the RA-02 module now. I set HW_VERSION=EU433 in the platformio.ini.

I build another pair of a Lolin32 Lite and a RA-02 module but can't get this flashed. I have the following output in the pio console after the succesful building of the firmware (using heltec):

CURRENT: upload_protocol = esptoolWarning! Please install 99-platformio-udev.rules. Looking for upload port...Mode details: https://docs.platformio.org/en/latest/faq.html#platformio-udev-rules Auto-detected: /dev/ttyUSB0Uploading .pio/build/heltec/firmware.binesptool.py v2.6Serial port /dev/ttyUSB0Connecting......Chip is ESP32D0WDQ6 (revision 1)Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme NoneMAC: 3c:71:bf:03:48:18Uploading stub...Running stub...Stub running...Changing baud rate to 921600Changed.Configuring flash size... A fatal error occurred: Invalid head of packet (0xE0)*** [upload] Error 2================================================================= [FAILED] Took 21.23 seconds =================================================================

I checked twice with the board if it's working and flashed another firmware and also did a flash_erase. Error stays the same.

Any ideas?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/meshtastic/Meshtastic-device/issues/84#issuecomment-640528166, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXB2JFUBC4AJ2466TE22LRVS7A7ANCNFSM4MDXSF6Q .

rradar commented 4 years ago

Try changing the upload speed in platformio.ini to 115200.

Once again, you are right! I were able to flash it but had no luck with the serial monitor (despite settings this one also to a baud rate of 115200). I added a oled display to see if things work like they should:

Lolin32 Lite + RA-02 + Oled image And it looks good (despite the little distortion of the small oled display with just 128x32 pixels)

My other setup:

Lolin32 + RA-02 image

Here I can see the serial and I get this:

Received someone rebroadcasting for us fr=0xfc,to=0xff,id=113
Adding packet record for fr=0xfc,to=0xff,id=113
FIXME not implementedRebroadcasting received floodmsg to neighbors, fr=0xfc,to=0xff,id=113,hop_limit=1
enqueuing for send on mesh fr=0xfc,to=0xff,id=113 (txGood=1,rxGood=1,rxBad=1)
FIXME-update-db Sniffing packet fr=0xfc,to=0xff,id=113
Notifying observers of received packet fr=0xfc,to=0xff,id=113
Trigger powerFSM 3
                  Ignoring incoming packet - not a position
NOTE! Received a nodenum collision we lost, so picking a new nodenum
Update DB node 0xfc, rx_time=0
old user !240ac49bbafc/Unknown bafc/?00
updating changed=0 user !240ac49bbafc/Unknown bafc/?00
sending owner !240ac49bbafc/Unknown bafc/?00
Update DB node 0xfc, rx_time=0
old user !240ac49bbafc/Unknown bafc/?00
updating changed=0 user !240ac49bbafc/Unknown bafc/?00
Adding packet record for fr=0xfc,to=0xff,id=209
enqueuing for send on mesh fr=0xfc,to=0xff,id=209 (txGood=1,rxGood=1,rxBad=1)
Forwarding to phone, from=0xfc, rx_time=0
Update DB node 0xfc, rx_time=0
old user !240ac49bbafc/Unknown bafc/?00
updating changed=0 user !240ac49bbafc/Unknown bafc/?00
Telling client we have new packets 1
Telling client we have new packets 1
Starting low level send from=0xfc, to=0xff, id=113, want_ack=0
Completed sending to=0xff, id=113
Starting low level send from=0xfc, to=0xff, id=209, want_ack=0
Completed sending to=0xff, id=209

looks like they are talking to each others :speaking_head:

I tried to get the app running via bluetooth but didn't succeeded so far...

geeksville commented 4 years ago

okay sounds like this bug has served its purpose. Closing. If you have other questions we can chat in another issue - or even better the forum.