looks awesome. I think to get the firmware running it is mostly a matter of making new ‘variant’ and board files for your board (which incidentally will make your board easily used for any other platformio based project).
I can help if you have questions (or if you can loan me a board I wouldn’t mind helping debug). How about we chat in this nrf52 dev channel:
https://app.slack.com/client/T0178GSES9E/C01835REKGT/thread/C0163V5NC79-1595764712.099800
Does look big. Any idea of a rough estimated BOM cost?
I have an InReach, and worked a gig with a bunch of people who used them regularly. Outside their HQ they had a sign reminding them to check their device for messages before going inside, and/or to leave it outside. But then it wouldn’t work in the winter because the batteries freeze pretty easily if just set outside.
I haven’t tested LoRa as much, but with no repeater right outside to relay through walls, there may be more non-obvious everyday patterns which would frustrate users of a keyboard integrated device.
That said, I think a keyboard device would be awesome as long as you know what to expect. There’s some discussion in this thread:
@geeksville Once I have confirmed all components working, I’ll try to compile meshtastic and probably send you a board.
At the moment I’m a little frustrated because I can upload firmware via the bootloader but it doesn’t start up on the device. What I did differently in v2.0 is occupy some of the qspi pins and leave out the flash chip, which i didn’t use in 1.0 either. Now I’m wondering whether the adafruit bootloader is making use of the qspi interface…does anyone know that? That would probably explain some stability issues I encountered during v1 testing.
If that is the case I might have to recompile the bootloader then which would be a slight pain because I’m only using the nordic sdk with Segger embedded Studio right now.
Sorry the slack link is not working for me for some reason…
You can assemble the thing in different configurations and leave many of the components out. The Bom cost spans between 30 and 50$
hmm - you might be happier with my fork of the adafruit bootloader (I had to make some changes):
Though I just looked through the commits and I don’t see anything that I think you’d definitely need.
Can you provide a link to your schematic (or at least the GPIO bindings) (I haven’t been following this thread super carefully)? I can take a look and see if there are any bootloader/appload changes I think you might need.
Thanks @geeksville ! Here it is:
If there is time I’ll take another look at it today.
Any idea how to make slack work?
Ok, I got some test firmware running and now the debug process begins.
Once again it was one of those I2C issues where you initially wonder whether it’s a hard or software issue. They were solved by desoldering the bme280 and now the fuel gauge works. The big E22 started behaving weirdly, it didnt transmit! I think the output stages are quite easy to fry. Actually so easy that you can even do it in software :(. I replaced the module and it’s transmitting now. What a tiresome process.
But at least I can now run some basic firmware and have variant files that are less confusing than in v1. The display works too but the upper and lower half are swapped.
You’ll definitely want to use the E22 mode I added in our sx1262 driver. See the ppr target in platform IO. With that flag set E22 works great.
For slack you should be able to sign in with this link:
Done. Thanks. Can the sx1262 talk to the sx1276 within the Meshtastic ecosystem? According to the manufacturer they should be able to communicate.
Man I really have to dive into PlatformIO, haven’t had the time yet because I was too obsessed with the hardware side. Those first tests have been done in Arduino for now to test the systems.
yep - my main test network is a mix of sx1276 and sx1262 based boards.
re: your schematic
I just took a look at the schematic and I think the existing code in meshtastic (including the E22 support) will “just work” for your board but you need to do three things:
At this point the board should be bootable and run meshtastic. The only thing that won’t be working is the display, someone will need to write a new adapter for the chip you used for the LCD.
(I’m happy to help if you have questions on chat - but this will be a little tricky to do only remote)
@einzeln00 is sending me a couple of boards. As soon as I have them (if someone else hasn’t already done so) - I’ll add support as described above.
Good instructions @geeksville! Please, add those instructions to the wiki, whenever you have time for that. 
Really cool. I created a variant within the platformio 0.9.1 project structure (LoRaBLERelayV2 to be consistent). My question is now: where do I define all the housekeeping stuff (all the extra pins for the lora module etc)?
I mean stuff like this:
#define DIO1 (44)//P1.12
#define DIO2 (28)//P0.28
#define TXEN (30)//P0.30
#define RXEN (4)//P0.04
#define L_SS (35)//P1.03
#define BUSY (40)//P1.08
#define L_RST (27)//P0.27
…or the boost converter enable pin.
In the end I’m also getting a compile error:
src\nrf52\NRF52CryptoEngine.cpp:4:10: fatal error: ocrypto_aes_ctr.h: No such file or directory
This whole Platformio stuff is really new to me. I’ve worked with many IDEs for STM32 and NRF5 before but I have yet to wrap my head around this one which is a great opportunity to learn about it. Sorry for being so noobish.
Good news: I got the “zolen” display to work now within arduino using u8g2 and this configuration:
//https://github.com/olikraus/u8g2/issues/321
U8G2_ST7565_64128N_F_4W_SW_SPI u8g2(U8G2_R2, /* clock=/DISP_CLK, / data=/ DISP_SDA, / cs=/ D_CS, / dc=/ D_RS, / reset=*/D_RES);
re: the crypto error message
I suspect you might have missed step 4 here: https://github.com/meshtastic/Meshtastic-device/blob/post1/docs/software/build-instructions.md
re: other stuff
Could you push this to a public github repo somewhere? (then it will be easier for me to pull and add comments by line number)
oh! I see why you were so confused. When I added RAK815 support I somehow mismerged the ppr/variant.h file. I’m fixing now, but in the meantime you can look at the correct version:
Also - you will need to do one manual hack to get your new board type building - because the upstream arduinonrf52 library doesn’t yet have the variants for your board (and it currently assumes that all variants live within that directory - I’m working with them to change this).
You will need to add a symbolic link to your particular new board variants directory. Here’s how I do it for the PPR board. You only need to do this nasty hack once.
$ ln -s ~/development/meshtastic/meshtastic-esp32/variants/ppr ~/.platformio/packages/framework-arduinoadafruitnrf52/variants
Cool, I’ll try to continue as soon as I have access to my dev PC again. I think the test sketch is almost mature enough to share it.
I did execute step 4 of the manual.
I really wish I had more time to poke around.
In today’s testing procedures I discovered more and more hardware bugs on the first v2 board. For example the fact that the Lora module knocks out the lithium protection circuit when firing at 1w and that I’ve swapped S and D on my p-channel mosfets. V2.1 is inevitable now
I recently stumbled across this chip:
https://insightsip.com/products/combo-smart-modules/isp4520
A LoRa NRF52 SoC
Maybe this is interesting for PCB development…
"The Semtech SX1261 (for EU and AS versions) or SX1262 (for US version) provide the LoRa radio function. "
OK, I added the variant files and crude test sketch to https://github.com/BigCorvus/LoRa-BLE-Relay-v2
Will continue working with platformIO as soon as I’m in town again.
awesome - I’ll use them this weekend and send a PR with any progress I make. I received two boards yesterday from @einzeln00 (1.1 version). I’ll start by checking against the schematics, programming the bootloader then slogging through getting the appload running.