Cant get SoftwareBitBang to work on Wemos D1 Mini

[mschmidi]

Hi, I just discovered PJON a couples of days ago. However this is exactly what i was looking for my garden project and i'm very exited. So i started with PJON/examples/ESP8266/Local/SoftwareBitBang/SendAndReceive/ unfortunately i could not make it work at all. Then i overcame the compiling error with the Arduino IDE 1.8.9. But still the Arduino Mini pro and the Wemos D1 Mini would not talk to each other - I got error message "connection lost to id 44" and vis versa. So i took 2 Arduino pro Mini and it worked straight away. After this i took 2 Wemos and still it would not work. I tried to use older libraries but still no luck, so i went back to Version 11.2. So at the Moment i'm sucked and i was wondering if someone could give me a hint where to search my mistake.

Thanks for your help, M.

[gioblu]

Ciao @mschmidi thank you very much for your report. I am still waiting for the Wemos D1, I can test only with ESP8266 NodeMCU 1.0 and ESP32 Heltech Lora. Testing with those I get nominal functionality.

Have you tried different pins? For now Wemos is not officially supported and some of its pins may not work as expected.

[mschmidi]

Thank you for your fast feedback. I will check and let you know.

[ulno]

I basically teach all my classes based on the wemos d1 mini. So far it has really behaved very similarly to the nodemcu 1.0. @mschmidi have you tested other pins if it would work there? If not, I might be able to run some tests here myself.

[mschmidi]

Hi @ulno I have tried all different pins unfortunately with no success. I ordered an nodemcu to see if i can make it work on this one. Would be great if you could test

[ulno]

As promised, I made some tests with two Wemos D1 minis. I flashed one with ESPTransmitter and one with the corresponding Receiver.

I tested both D1 to D1 and D5 to D5 communication -> both worked with and without 1MOhm termination, I did conenct common ground (not tested without, but would probably work as connected to same USB-hub).

However, going there was not straight forward. Unfortunately, anything PJON-related does not compile for the ESP. It fails with:

In file included from /home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/LocalUDP.h:24:0,
                 from /home/ulno/Arduino/libraries/PJON/src/strategies/PJON_Strategies.h:77,
                 from /home/ulno/Arduino/libraries/PJON/src/PJON.h:96,
                 from /tmp/arduino_modified_sketch_246565/ESPTransmitter.ino:6:
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h: In member function 'void UDPHelper::send_string(uint8_t*, uint16_t)':
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:19: error: ambiguous overload for 'operator~' (operand type is 'IPAddress')
     broadcastIp = ~WiFi.subnetMask() | WiFi.localIP();
                   ^
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:19: note: candidates are:
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:19: note: operator~(uint32_t {aka unsigned int}) <built-in>
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:19: note: operator~(u32_t {aka long unsigned int}) <built-in>
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:19: note: operator~(int) <built-in>
exit status 1
Error compiling for board LOLIN(WEMOS) D1 R2 & mini.

I know there have been massive changes in the ESP Wireless stack recently, so I needed to add

#define PJON_INCLUDE_SWBB

before including PJON.h

This made it compile.

I also wasted some test time to realize that the receiver uses by default Pin 12 not D1/GPIO5, so maybe the ESP examples should be adjusted and commented accordingly (at anybody of the people who have forked already - can someone change that and make a PR?)

However, after all this, compilation and flashing went smooth (I set "LOLIN WEMOS(D1) R2 & mini" as board) and Bitbang worked at least on Two ports well - I would actually expect it to work well on most of the GPIO ports. @gioblu why does it say in the documentation that only D1 is supported? Even I2C works I think on all GPIO ports (maybe not D4 as that one has a pull-up on some boards).

One more issue: Serial Monitor of Arduino IDE is broken on several Linux Distros currently due to weird Java dependencies of this (IMHO horrible) IDE. Make sure to use an independent serial monitor in Linux or directly switch to platformio and dump Arduino IDE.

[gioblu]

Ciao @ulno thank you very much for your support. I will fix the examples and reference the commits as you suggested as soon as possible.

@fredilarsen have you noticed this error?

The motivation why not all pins work can be found here: https://github.com/gioblu/PJON/blob/master/src/strategies/SoftwareBitBang/Timing is related to subtle differences that each pin has in the time required to change its state or its mode if compared to the others (being the implementation on the level of the "pin" must conditionally resolve the registers).

About the Arduino IDE, as you, I don't love it, although I suspect a big slice of our users uses that and has no familiarity with more advanced alternatives, so its support cannot be dropped. Although I agree with you that for sure we will need to work out some examples expressly dedicated to platformio users.

[fredilarsen]

@gioblu I do not get this error here with Arduino 1.8.9 and Generic ESP8266 module, NodeMCU 0.9 or WeMos D1 R1,

But from the error in the above post it seems something (library? compiler?) has changed so that the compiler does not know which implementation of the operator to use. A simple typecast should fix it: broadcastIP = ~(uint32_t)WiFi.subnetMask() | WiFi.localIP();

[gioblu]

Ciao @fredilarsen thank you very much for running tests. The same here, on Arduino 1.8.9 NodeMCU 1.0 compiles fine.

[gioblu]

Ciao @ulno could you give a try to the change proposed by @fredilarsen and see if that fixes the compilation error?

[ulno]

Ok, I will check it this weekend (can't do it before) and create a PR when successful.

[gioblu]

Thank you very much for you support @ulno

[mschmidi]

hi guys,

Thank you all for your efforts. I was able to make it work with 2 Wemos D1 mini, or by using 2 arduino pro mini. however if i mix them up (using 1 mini and 1 wemos) i can't make it work. I saw that the mini is not officially support but since it worked if i use 2 of them i'm really wondering if its really not possible. I rather would like to believe that i'm just too stupid... has anybody a hint for me?

Thanxs m.

[ulno]

@mschmidi Cool that it works now.

Just to confirm, is the arduino pro mini also based 3.3V or on 5V?

That's one of the reasons I love i2c as it's low active and allows to (easily) connect microcontrollers with different core voltages together without a level shifter (@gioblu Any way to design a pull low - to common ground - scheme using analog ports on Arduino like i2c - SoftwareBitBang?).

However, the documentation of SoftwareBitBang mentions some resistor computation scheme dependent on the voltages - @mschmidi - if pro mini is not 3.3V core, have you computed these correctly and attached resistors correspondently?

Or would these resistors not influence the transmission and just the lifespan of the lower voltage devices?

[gioblu]

Ciao @mschmidi and @ulno

The motivation why it does not work mixing the Arduino Pro mini with Wemos is because the pro-mini is not supported for now and so generates bits of slightly different durations. It would need a dedicated timing setup here: https://github.com/gioblu/PJON/blob/master/src/strategies/SoftwareBitBang/Timing.h As soon as I will be able to release v12.0 I will take some time to focus on the Arduino Mini compatibility, that was requested already a while ago.

If the 3v3 side is 5v tolerant SoftwareBitBang works out of the box also with a bare wire connection (no pull-down or current limiting resistors although it is strongly suggested to place them if the setup is definitive). You can test that connecting an ESP8266 or a SAMD with an Arduino UNO, nano or mega. Because of how PJDL is specified devices with diferrent voltages can coexist with no issues (if their pins can tolerate the highest voltage used).

@ulno the resistors mentioned here are the pull-down resistors:

1-5 MΩ pull-down resistor as shown in the graph above to reduce externally induced interference.

Or resistor placed to ground induced voltage in the line, that if exceeds the threshold between 1 and 0 could corrupt packets and or just consume bandwidth. If you are running the NetworkAnalysis example and you get a lot of times busy, that generally means you need a pull-down resistor.

and the current-limiting resistors:

Pins can be optionally protected against overload adding a current limiting resistor to each connected pin. The resistor value can be obtained solving the following equation R = (operating voltage / pin max current drain), for example to obtain the current limiting resistor value for an Arduino Uno simply substitute its characteristics: R = (5v / 0.030A) = 166.66Ω.

This optional resistors are suggested on definitive setups to protect the pin, in rare cases in which it could fry, because of a high voltage induced in the line, for example because of lightning strikes or other sources of transient induction.

I do see i2c, using 2 wires and being designed for a different purpose, or to connect chips on the same pcb or pcbs in the range of few meters, being generous, as the wrong candidate for an alternative or a comparison with PJDL, that is more an alternative to 1-wire.

I do have to agree, the implementation is pretty naive, and that makes hard for users to work out the compatibility of the unsupported ics, because it needs an oscilloscope and some experience. I should work out a precise guide for this.

I would see as a good sign the fact that the pro-mini are able to communicate between each other. I promise I will work out the required timing setup as soon as possible and I am sorry @mschmidi if you wasted some time because of this.

[gioblu]

@mschmidi @ulno if you want to attempt to find the correct timing setup:

1. Find a constant that can let you identify the pro-mini as it is done here for example
2. Use a compatible device and flash it with Local/SoftwareBitBang/NetworkAnalysis/Transmitter
3. If you have an oscilloscope, do the same with the unsupported device, look and measure bit duration of both devices, if they differ you must change the setup of SWBB_BIT_WIDTH and SWBB_BIT_SPACER of the unsupported device until you get the same durations produced by the supported device.
4. Flash the unsupported device with the Local/SoftwareBitBang/SpeedTest/Receiver example with SWBB_READ_DELAY tweaked and evaluate the result, iterate if not acceptable. Remember to tweak only the timing setup of the unsupported device. Specially for devices part of the same family or with minor differences it is generally enough to tweak the SWBB_READ_DELAY to get it through.
5. If no progress is obtained or the result is satisfactory the programs must be inverted so, the unsupported device must run the transmitter example and the supported device the receiver example. If you don't have an oscilloscope and the result is not satisfactory you can try tweaking SWBB_BIT_WIDTH and or SWBB_BIT_SPACER of the unsupported device slightly by trial and error.
6. Do again point 2 and 4, if the performance has degraded or before was not working at all, you may still need to slightly tweak SWBB_READ_DELAY

Ah, be sure that your board has at least an external 16MHz oscillator. I have not been able to get even mode 1 working with 8MHz or 16MHz internal PPL clock, or 8MHz external oscillator. 16MHz external oscillator required.

[ulno]

@gioblu I do not get this error here with Arduino 1.8.9 and Generic ESP8266 module, NodeMCU 0.9 or WeMos D1 R1,

But from the error in the above post it seems something (library? compiler?) has changed so that the compiler does not know which implementation of the operator to use. A simple typecast should fix it: broadcastIP = ~(uint32_t)WiFi.subnetMask() | WiFi.localIP();

even if changing to broadcastIp = ~(uint32_t)WiFi.subnetMask() | WiFi.localIP(); (small p in Ip), I get both on generic esp8266 and for wemos d1 mini:

In file included from /home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/LocalUDP.h:24:0,
                 from /home/ulno/Arduino/libraries/PJON/src/strategies/PJON_Strategies.h:77,
                 from /home/ulno/Arduino/libraries/PJON/src/PJON.h:96,
                 from /tmp/arduino_modified_sketch_158861/Receiver.ino:6:
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h: In member function 'void UDPHelper::send_string(uint8_t*, uint16_t)':
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:48: error: ambiguous overload for 'operator|' (operand types are 'uint32_t {aka unsigned int}' and 'IPAddress')
     broadcastIp = ~(uint32_t)WiFi.subnetMask() | WiFi.localIP();
                                                ^
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:48: note: candidates are:
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:48: note: operator|(uint32_t {aka unsigned int}, uint32_t {aka unsigned int}) <built-in>
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:48: note: operator|(uint32_t {aka unsigned int}, u32_t {aka long unsigned int}) <built-in>
/home/ulno/Arduino/libraries/PJON/src/strategies/LocalUDP/../../interfaces/ARDUINO/UDPHelper_ARDUINO.h:87:48: note: operator|(uint32_t {aka unsigned int}, int) <built-in>

I use Arduino IDE 1.8.9, esp8266 boards version 2.5.1. Any other ideas?

[gioblu]

Ciao @ulno first of all, thank you very much for dedicating effort to run tests. I do see in master there is an additional typecast here: https://github.com/gioblu/PJON/blob/master/src/interfaces/ARDUINO/UDPHelper_ARDUINO.h#L87

Be sure to use master and not 11.2

[ulno]

Ah, that looks promising.

Not running master yet - still testing out PJON in Arduino IDE (even if telling that's not my favorite environment), but planning on using it in my teaching (IoT introduction) in November - however some things have been coming up here which only allow me to run small tests.

Just added the second typecast and can confirm that this makes it compile again, so I guess when I start serious testing next month it will be already mainlined.

@gioblu Thanks for keeping such a friendly, welcoming, and appreciative tone in this community, I am looking forward to contributing more when time allows.

[gioblu]

@ulno it is a huge pleasure to hear that :) if you need any help feel free to write me personally here gioscarab@gmail.com or publicly using our gitter chat here https://gitter.im/gioblu/PJON

Thank you for reporting the fix to the examples :)