Heltec ESP32 Lora32 V3 OLED issue fix

 I am using different ESP32 Lora boards, not for LORA but for their included modem chips which can be used to receive 868MHz sensors like in my https://github.com/seife/lacrosse2mqtt project.

Now I got a new one, "Heltec ESP32 Lora32 V3" and this one did not want to light up its OLED. The hardware is not broken, as the factory-shipped software did use the display, but with my own examples, it stayed dark.

Searching the internet found that other people had the same issue but the only solution that was to be found was using Heltec's own horribly hacked library versions, which I did not want.

So I examined the differences between the Heltec version and the original https://github.com/ThingPulse/esp8266-oled-ssd1306 and the solution was simple, even though it is well hidden:

You need to enable the VEXT pin (by pulling its GPIO to low), like this in your setup() function:

#if defined(WIFI_LoRa_32_V3)

pinMode(Vext, OUTPUT);

digitalWrite(Vext, LOW);

delay(10); /* allow to settle */

#endif

/* pull low reset pin, then display.init() as usual */

That's it. Now it is working as with the other boards before.

LIRC IRMP remote control code "sharing"

While investigating inferior LIRC performance today, I checked the timings used by IRMP and found that using those instead of the "measured" ones of LIRC in the config file made LIRC perform much better. See the patch for details.

Looking at the lircd.conf more thoroughly for the first time, I finally found the similarities between the lircd remote control codes and the IRMP codes (at least for the NEC protocol used with this handset):

• IRMP "address": 0xBA45


• IRMP "command": 0x1A


• lircd "pre_data": 0xA25D


• lircd "code": 0x58A7

The IRMP Documentation (sorry, german only) describes the NEC protocol as follows:

32 bits of data: 8 address bits + 8 inverted address bits + 8 command bits + 8 inverted command bits

The IRMP "address" is really 8 bit only: 0xBA inverted is 0x45, leading to an "effective address" of 0x45.
The IRMP "command" is already 8 bit only.

Now double-check with the lirc codes: address 0xA2 inverted = 0x5D, command 0x58 inverted = 0xA7, so the scheme seems to apply to both.

Using only the relevant 8 bits:

• IRMP address: 0x45


• IRMP command: 0x1A


• lircd address: 0xA2


• lircd command: 0x58

Looking closely, I found that the difference is actually the LSB / MSB order: IRMP is shifting the bits in reverse order compared to lircd.

So if needed, it should now be pretty easy to extract codes for IRMP from lircd.conf files using a simple perl script or the other way round, at least for NEC codes. Lircd has the advantage that you can easily "learn" your new remote control handset with an interactive program (if you disregard the suboptimal timing data it creates).

Using IRMP with Arduino

I needed to implement an infrared remote control decoder, so certainly I took out my Arduino and hooked up an IR sensor chip to pin 2. Then the interesting thing started. Looking around, I found ladyada's tutorial on IR sensors. However, the method used there is pretty limited (you basically record a sample of each key signal and then compare the received signal to your samples) and unreliable for many protocols.
Then I found IRMP (german only link, sorry) which is a very versatile IR decoder for many protocols. However, IRMP is made to be used with plain avr-gcc, not from within Arduino's IDE.
But fixing that was really not very hard.
The results are available on gitorious, project arduino-addons/irmp-arduino, including a simple example sketch to test the decoder.

Note that I'll probably rebase the git tree whenever something happens in the IRMP SVN repository, so be aware of that in case you make local changes to the code and want to update from my tree.

Have fun! :-)

new avr-gcc packages

Thanks to Volker Kuhlmann, there are now 3 brand new avr-gcc packages in the CrossToolchain:avr repository: avr-gcc-436, avr-gcc-462 and avr-gcc-47-20111105.
The "original" cross-avr-gcc package is still at 4.3.3, as that's the most tested revision and also it has additional patches that are dropped from the new versions. Those patches add, amongst others, XMEGA support which is not present in the avr-gcc packages. That's something to improve in the future.

The packages contain a run-avr-gcc-XXX wrapper script (substitute XXX with the 436, 462,...) to make testing the respective compiler very easy.

Have fun testing!

My first remotely useful Arduino sketch

I want to use the arduino to interface a small graphic LCD to my satellite set-top-boxes.
The problem with most of the boxes you can buy today is, that they only have a one-line, 12-16 character text-only VFD display and no longer the nice credit-card sized graphic LCDs the old dbox2 or dreamboxes had.
Most new boxes have an USB port,though, so interfacing the LCD via USB is pretty easy.
The code (both arduino and a small test program for the box) is here on gitorious. The protocol is primitive but pretty efficient on RAM and it does recover from errors surprisingly well. The update rate of maybe 10 FPS is enough for this kind of usage.
Now I need to implement some "display driving daemon" which can be interfaced easily with the set-top-box software.

New toy: Arduino (packages fixed)

So I finally got an arduino or more precisely, a nice starter kit from fritzing.org.

Unboxing pictures are here.

I followed the instructions on installing the software from OBS, but checked the repositories first and found that there were some problems with FACTORY builds in Klaus' repo.
Additionally, the packages are, even if made to build, not working with the arduino uno thats in the starterkit.

The reasons are

• arduino uno has a different USB controller and appears as ACM device, not usbserial


• apparently, the avrdude included in CrossToolchain:avr is newer than what the arduino software expects and thus does need another protocol specification


• the arduino package sports its own avrdude.conf which does not work with the uno

Of course I fixed all those problems (and submitrequested the fixes back to the "upstream" projects) in the temporary project home:seife:arduino :-)
So now all you should need to do to get the first program uploaded to the uno is:

• add the home:seife:arduino repository


• add the CrossToolchain:avr repository


• zypper install arduino


• add your user to the dialout group (we could create some special udev rule case that discovers the arduino and makes the device accessible for group "users", but that would not help for the other arduinos that come with FT232 usb-serial interfaces)


• relogin to activate your dialout group membership


• start "arduino" from a terminal (the package is missing a desktop file, I will try to fix that later)

You can also install the fritzing package, but probably better use the package from the Education project than that from Contrib since Education seems to contain a much more recent package.
But for now, everything I did was done using arduino.

Now looking at what is needed to get this to work, I'm wondering if the arduino related packages should just be put into CrossToolchain:avr, or if we should create some project for this Arduino stuff, containing the arduino and fritzing packages and everything needed to support them.
An argument against the "stand alone Arduino project" would be that it duplicates significant build efforts (the cross-avr packages are probably pretty expensive to build).
The pro agument is, that interested users need to add only one repository. If even fritzing is there, they need not add the "Education" repo. This would be good, because adding such big repos which also contain lots of updated "standard" packages (there's SDL etc. in Education) is certainly not recommended for novice users because of the unpredictable side effects. Note that the CrossToolchain:avr repo is pretty small and does not contain anything that updates system tools or similar, so adding this one should be "mostly harmless".

I'll need to think about this and maybe talk with other involved parties at the openSUSE conference in two weeks...