Add support for a new nRF variant constructed by soldering an E22

[brad112358]

module directly to a Pro Micro type nRF52840 board.

This variant supports the easy DIY pocket node which I have documented with detailed build instructions here: https://github.com/brad112358/easy_E22

This method of construction takes advantage of the flexible pin to function assignment the nRF52 offers to eliminate the need for a breadboard or custom PCB. The Ebyte E22 900M33S LoRa module is actually a very good fit for a battery powered device. The LNA and full 1 watt of output power it provides on 3.7 volts are significant advantages over the bare LoRa chip designs which are so common.

This is my first Meshtastic PR.

Thanks!

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[brad112358]

Why was this pr ignored and closed?

[brad112358]

I'm not sure why this got no attention for so long. Then I missed the stale label and now it's closed and it seems my previous comment asking why is also being ignored. This is very discouraging because I spent a lot of time developing detailed build instructions for this high power, easy DIY node with few wires and no custom PCB required because there don't seem to be many (any?) commercial 1 W mobile nodes.

(guessing now on who to ask) @vidplace7 @thebentern can this be re-opened? Do I need to open a new PR? Should I just give up?

[fifieldt]

Hi @brad112358 , I'm sorry your first patch to Meshtastic has been a bad experience.

The honest truth is, all of the people (volunteers) who could review and comment have just been very busy since August. We've been pushing hard to get a stable beta 2.7 release out, which has had some heavy lifts in areas like Bluetooth. DIY aficionados such as yourself are very important too, but we've just been focused on other things for a few months. I personally have a patch that's been waiting a similar time, so know how annoying this is!

@NomDeTom is an E22 expert, who might be able to take a look. Otherwise, the nrf52 channel in discord ha a wealth of knowledge, including people who might want to build one of your boards.

Sorry again, we're just swamped.

[fifieldt]

To make this easier to merge, would it be possible to change the base to the develop branch? Master is in a feature freeze right now while we work on the beta release.

[wlockwood]

I'm not sure why this got no attention for so long. Then I missed the stale label and now it's closed and it seems my previous comment asking why is also being ignored. This is very discouraging because I spent a lot of time developing detailed build instructions for this high power, easy DIY node with few wires and no custom PCB required because there don't seem to be many (any?) commercial 1 W mobile nodes.

If it helps, my group was hugely inspired by your work on this and we're planning to build a bunch of what we're calling Janktastic.
https://www.reddit.com/r/meshtastic/comments/1oglyf3/my_pocket_node_1w_e22_radio_diy/

[brad112358]

@fifieldt Thanks for re-opening this! I completely understand the development team being busy on higher priority work. I'll continue to try to be patient. My frustration wasn't so much with the delay as that I thought I was being patient on my end, but my patience was rewarded with the PR being closed by a impatient robot with no way for me to re-open.

I have changed the base of the PR to develop as requested. I've also taken this opportunity to rebase and squash commits.

[brad112358]

@wlockwood Thanks for your supportive comment! I took a look at the nodes you have been building. This isn't the best place for a lengthy discussion of design choices, but I will point out a couple of observations which are also relevant here because they are reasons I need a new variant and can't use the existing nrf52_promicro_diy_tcxo as you are doing.

First, for a simple 1S Lipo or LiIon powered (no voltage boost) design with the goal of 1W output, you really need to use an E22-900M33S, not the slightly cheaper E22-900M30S which is supported by the existing variants and which you are using. This is because both versions of the E22 only reach close to their rated power when supplied with at least 5 volts and the 33S version comes much closer to it's rated output in the 3 to 4.1 volt range which is what both of our designs are supplying. The 30S version only outputs about 70mw at 3.0 volts (much lower than a bare SX chip!) and about 500mw at 4 volts. The 33S version outputs between about 500mw and 1.1 w in this voltage range, very close our goal of the maximum legal power.

Unfortunately, there is no way for the firmware to check which E22 variant is used so the pre-compiled firmware which Meshtastic provides for the nrf52_promicro_diy_tcxo variant does not support the 33S variant. In fact, if you attempt to use the 33S with this firmware, you will destroy it's power amp because the Meshtastic default power output setting is larger than the 8dBm maximum which the 33S allows!

I also wanted my design to be as simple to build as possible while not requiring a PCB. This is the second reason I couldn't use the existing variants as I wanted pin assignments which allow soldering the ProMicro and E22 directly together back to back.

[wlockwood]

In fact, if you attempt to use the 33S with this firmware, you will destroy it's power amp because the Meshtastic default power output setting is larger than the 8dBm maximum which the 33S allows!

If the output is so much lower on 3V but the MCU still works, could you do the initial boot and config on 3V, set the output level, then raise the power to 5V?

Also, thanks for your detailed response. I sent the link for this conversation to my group.

[brad112358]

Also, thanks for your detailed response. I sent the link for this conversation to my group.

This isn't the best place for node design discussions. I've sent you an email. If you didn't receive it, let me know where I can contact you.

[brad112358]

Another month has passed and I see a beta has been released. @NomDeTom Do you have time to review and comment on this PR?

[NomDeTom]

I'll be honest, I forgot about this. I have been thinking about adding this pinout to the existing promicro variant.h and platform.ini, to keep it together with the existing files. @brad112358 how does that work for you?

[brad112358]

I have been thinking about adding this pinout to the existing promicro variant.h and platform.ini, to keep it together with the existing files. @brad112358 how does that work for you?

Yes, I think I'd be happy with that, especially if this approach makes it easier to get to the point of the project providing pre-built firmware for this pinout. If only one pre-built firmware for this pinout is provided, I suggest that it needs have MAX_POWER set to 8. I think this is also a problem with the existing promicro firmware as it would be easy for a user to mistakenly use the pre-built firmware with an E22-900M33S and burn out the power amp.

[NomDeTom]

ah, I don't think it will make it through to being officially built or in the flasher, but it will be very easy to make it using the github actions. See here:
#8839

[brad112358]

See here: #8839

Very cool. I didn't realize this build action existed and I'm not very familiar with github actions. Am I correct that this requires that a user have a github account and create their own fork to build a target?

How do you want to proceed? Should I modify this PR to integrate this pinout with the existing nrf52_promicro_diy_tcxo variant or would you prefer to do the work yourself? If you want me to do it, what should we name the new target(s)?

[NomDeTom]

Am I correct that this requires that a user have a github account and create their own fork to build a target?

Yes, that's the idea.

How do you want to proceed? Should I modify this PR to integrate this pinout with the existing nrf52_promicro_diy_tcxo variant or would you prefer to do the work yourself? If you want me to do it, what should we name the new target(s)?

I'll try and make a pull request to your branch with the necessary changes, and then we'll go from there.

[fifieldt]

Thanks so much for looking at this Tom

[brad112358]

@NomDeTom I haven't seen the PR you proposed to integrate this with nrf52_promicro_diy_tcxo so I'm guessing you have been short on time. This PR is now 5 months old. Is there anything I can do to help move this along? Should I take a crack at integrating it myself?

I've updated this PR to clean up the battery monitoring defines and add buzzer and screen support.

[NomDeTom]

@brad112358 sort of. I've been working to make the Xiao NRF52 variants work using a combined technique first, and that hasn't gone as well as I hoped. This is still on my radar.

[brad112358]

@NomDeTom Are the XIAO variants even popular? From what I can see, they are more expensive than than the Promicro boards and don't appear to have enough pins exposed for peripherals. Anyway, is there anything at all I can do to help?

[radonslide]

It's disappointing to see that this PR has been closed again. I'm very happy with this DIY hardware and how it works. I would have thought it would be included in the sources this time.

[brad112358]

@fifieldt Can we get this re-opened please? @NomDeTom Do you still intend to merge this with your other work? Is there anything I can do to help move this along so it doesn't get closed every time I take my eye off of it?

[NomDeTom]

@brad112358
Can you do me a few things, please?

1. Update your branch to include the latest develop changes
2. Confirm the pins you're using (mid board) are for GPS RX and GPS TX - the naming convention in the code has swapped, but the pins should not have done so:
   | P1.02 | GPS_TX | This is the tx pin of the GPS (i.e. sending data to the MCU)?
   | P1.07 | GPS_RX | This is the rx pin of the GPS (i.e. receiving data from the MCU)?
3. Confirm you're putting the buzzer on P0.08 - it's in the code but not the pin chart. Also consider moving this to P0.06 - see below.
4. Consider placing the user button on P0.08, especially if you're not using serial2 - user buttons are usually recommended if you're adding a buzzer, if only to silence the damn thing.

If you can confirm the above, I'll tweak the main file to include your pinout as an option.

[NomDeTom]

@brad112358
If you want to check your pinout against this, that'd be awesome.
develop...NomDeTom:MeshtasticFirmware:brad_easy_promicro

[brad112358]

2. Confirm the pins you're using (mid board) are for GPS RX and GPS TX - the naming convention in the code has swapped, but the pins should not have done so:
   | P1.02 | GPS_TX | This is the tx pin of the GPS (i.e. sending data to the MCU)?
   | P1.07 | GPS_RX | This is the rx pin of the GPS (i.e. receiving data from the MCU)?

Nasty. This explains how it seemed to have changed last time I updated firmware!

My current code and the above are incorrect and I ended up overriding it in position settings, but I haven't looped back to update the code. GPS TX, MCU RX should be P1.07 and GPS RX, MCU TX should be P1.02.

This allows me to solder these pins directly via header pins with the GPS board I'm using.

3. Confirm you're putting the buzzer on P0.08 - it's in the code but not the pin chart. Also consider moving this to P0.06 - see below.

Yes, my buzzer is on p0.08

This allows me to solder the buzzer directly to this pad and the USB connector. I haven't updated my build instructions with these pictures yet.

4. Consider placing the user button on P0.08, especially if you're not using serial2 - user buttons are usually recommended if you're adding a buzzer, if only to silence the damn thing.

Is there some reason not to put the buzzer on p0.08?

A button could be added on P0.06. But my recent builds include a rotary encoder instead, with A on p0.22, B on P0.20, and Press on P0.24. I will be updating my build instructions shortly. Am I correct that there are no defines for these pins available to variants and that they must be configured at run time via the Canned Messasge settings?

I will update this PR when I get some time, perhaps later today.

[NomDeTom]

Ah, my idea had been to pair the p0.08 with the ground pin as a user button, to match the reset pin opposite. It would probably work equally well with p0.06, tbh.

[brad112358]

@NomDeTom I have pushed an update which corrects the GPS defines and adds a button pin and documents the pins I'm using for the rotary encoder. I've tested this code on my hardware and confirmed I no longer need to override the GPS pins in settings

Would it help if I did a PR against your brad_easy_promicro branch to account for these changes?