Electronics - BrixIT Blog

Can't get blinky on the BL602

Martijn Braam — Mon, 01 May 2023 16:46:41 -0000

One of the boards I have in my parts box is the PINE64 BL602 evaluation board. The "PineCone". It's a competitor to WiFi enabled microcontrollers like the Espressif products.

I put it aside since when I received it there was not really any software to go along with it and I don't have anywhere near the experience to bring up a board like this.

Getting blinky running 3 years laters

This product has been out for 3 years now so lets see if it has formed a community.

So if you are not familiar with blinky, it's the Hello World! of the microcontroller world. The goal is have a led connected to one pin of the board and toggle that pin on and off every second to make a blinking led.

Let's check the website first. The official page for this from PINE64 itself is https://pine64.com/product/pinecone-bl602-evaluation-board/. Since the only official thing is the webshop which doesn't list any documentation or links to progress further on how to use this thing I consider it a dead end. Let's move on to the pine64.org side.

The community side is the wiki page at https://wiki.pine64.org/wiki/PineCone. This has the specs again and a block diagram. It also has the datasheets for the components on the board and the schematics. Not anything I actually need to get started using this product.

Let's compare to the Raspberry Pi Pico, a competitor that's doing quite well. When you search for this you land on the official product page https://www.raspberrypi.com/products/raspberry-pi-pico/ that has the shop link, the specifications but more importantly it's a hub linking to the "Getting started" guide and the documentation for users.

So lets scroll down on the PineCone wiki page since it's my only hope for docs. Thee quarters down this long wiki page is a list of flashing utilities. I don't have anything to flash yet but I look forward to figuring which of the 6 listed flashers fits my personality best /s.

The rest of this page is links to random github repositories and blog articles. The top link being the link to the SDK for this board. It links to https://github.com/pine64/bl_iot_sdk and is labeled as "compilers, linkers, and all the code to build on Windows, Linux (x86_64), and MacOS". The last activity here was 2 years ago. This seems mostly focussed on the reverse engineering effort but lets have a look.

bl_iot_sdk

This repository has a README with again more links to a lot of different places. One of these is linking to https://pine64.github.io/bl602-docs/ which is a sphinx generated documentation site. This is several pages too deep from the official pine64 website but I forgive that since it has the magical words I've been looking for:

So I'm going down this path, it almost seems familiar to the way the Pi Pico sdk is used. Clone the repository and create an environment variable pointing to the checkout folder.

Next it tells me how to compile the example apps, but I don't want to compile the example apps, those probably work and they are in-tree so those probaby Just Work(tm) without setting up the scaffolding you should do for your own projects. I just want to build a main.c that does blinky. This part of the documentation sadly stops after compiling and flashing the built-in apps.

I have continued browsing this documentation for a bit but it does not show at all how to make a minimal blinky example and build it. The rest of the documentation is mainly using the advanced features, various flashing systems and debugging systems and image formats.

So to compare this with the Pi Pico documentation: The first thing I find when I read the documentation of the SDK is:

Blinky in the Pi Pico docs

Chapter 1.2 is the first chapter with actual documentation and it starts with all the things I want for getting started with yet another microcontroller board:

A very simple .c file that implements blinky without using any advanced features of the hardware.
The output of tree showing exactly which folder structure I should have and where the files go
The CMakeLists.txt that builds this application

The BL602 documentation has shown me none of the above yet. At this point I give up and just open 20 tabs in my browser with all the linked pages from the wiki.

All these links are random flashing utilities, porting new programming languages and porting new frameworks. Also a lot of them showing how to flash the example apps to the thing.

PEOPLE DON'T BUY MICROCONTROLLERS TO FLASH EXISTING EXAMPLES

Getting ANYTHING to run

So there is no documentation on how to make blinky for this platform whatsoever. I give up and figure it out myself from the sdk example apps.

There's no blinky in the examples, the simplest application I could find was the helloworld one that outputs some text over uart. This uses FreeRTOS to get that working so there's a complete lack of basic single .c file demo applications for this.

More issues

This SDK has multiple things I don't like. The most important one is that it ships prebuilt compilers in the source tree. This is not a proper SDK, this is some Android-level build mess.

The whole point of using nice RISC-V boards is that this is a standard architecture, all Linux distributions already ship a maintained RISC-V toolchain so why would I ever use some random precompiled binaries shipped by a Chinese vendor.

Why is this using Makefiles to build the thing instead of cmake which the Raspberry Pi foundation have already proven you can integrate way neater. This is just throwing hardware over the wall and linking to the chip vendor documentation, hoping the community can match a proper made tutorial, proper documentation and make a new SDK that's not a mess.

I guess I just dump this thing back in the parts bin and wait some years. Quite sad since this seems to be some really nice hardware and a great alternative to the existing microcontroller platforms.

Sensors and PCB design

Martijn Braam — Thu, 02 Mar 2023 20:09:12 -0000

I do a lot of software development, I do enough of it to be comfortable with the process. I have worked on enough projects and have made enough pieces of software that it's quite easy to quickly spin up a new project to fix a specific issue I'm having.

Hardware design is a whole other can of worms. I have played with things like the Arduino and later the STM32 chips, ESP8266 and RP2040. These things are quite neat from a programmers perspective. You write your code in c++ and the included toolchain figures out all the hard parts and flashes the board. Hardware design is also quite simple since it's mostly putting together different hardware modules and breakout boards. Only a basic understanding of the hardware busses is required to get stuff up and running.

Projects usually look like the picture above. No resistors, capacitors or other components are needed. Just a breadboard (also optional), jumper wires and the IO modules you need to make your idea work.

Power is dealt with by the microcontroller board, the modules already include the pull-up resistors and power regulators required and the programmer is also included already.

The software side is also simplified and abstracted to the point where it's harder to get your average javascript project working than the embedded projects. You'd never have to open the 440 page atmega 328p manual to write the firmware. You don't even need to know about the register map for GPIO pins since things like digitalWrite(pin, state) exist.

It's easy to get a complete prototype running like this but then what?

Putting things in production

By far the easiest way to put the project in production is just shoving the breadboard in a project box and declaring it done. It works but it's not neat. This works if you only need one and it's for yourself.

When you need 5? 10? 30? of the same thing then breadboarding it will become a lot less practical. In some cases it's easy enough to just stick the modules on a piece of protoboard and solder it together. When that doesn't scale another option is putting the modules on a custom PCB.

This is exactly what I did for a project. This is the first PCB I have ever designed and put into production:

It's a PCB that only has pinheaders and connectors on it. This board would have a nodeMCU module and an off-the-shelf rs485 module on it. The board itself is incredibly simple but it did give me a chance to run through the complete process of going from a schematic to an actual physical product. Since it has no actual components on it it has removed a lot of worry if the board will work at all.

In this case the board was designed because I needed 15 of this design and this makes a lot more reliable and easy to maintain with the possibility to have neat screw terminals on it for the external connections.

Optimizing the design more

The above design was simple enough to not worry about optimizing it, but another project I wanted to take on is replacing my various sensor nodes with a neater custom design.

These boards have been put together around various ESP8266 dev boards, most of them are nodeMCU v3 boards, some are off-the-shelf boards that I receive data from with an rtl-sdr.

My plan is to make the one board to rule them all. A custom designed board that makes it easy to connect my existing sensors and allows a bit of extension. The design is based around an ESP-12F module since all my existing sensor code is already written for the various ESP8266 boards. It's also in stock at LCSC so that makes it a lot easier to get fabricated.

The design goals for this custom board is:

On-board programmer for development
Have the ESP module hooked up so it can deep sleep properly
Have a built in temperature sensor. Most of my external sensor boards are already temperature/humidity sensors so it makes sense to just include it since it's a cheap chip.
Have a screw terminal for hooking up onewire devices
Expose a silkscreen marked SPI and I2C bus
Be able to be powered with an USB Type-C cable or a single lithium cell.
Have a built-in charger for the lithium cell.
The board should be able to be assembled by JLCPCB and Aisler

For implementing this I mostly looked at the nodeMCU v3 schematic as reference and also made the basic layout of the PCB similar to that board. Initially I wanted to add the very popular DS18B20 onewire temperature sensor on-board but that got replaced with the SHT30 module that also includes a humidity sensor and connects to the I2C bus instead.

For the programming and USB part I included the CP2102 USB-to-serial converter chip that was also included on the nodeMCU board. It is probably overkill for this application though since I'm not using any of the functionality of that chip beside the RX/TX pins. I dropped the auto-reset circuit since I was worried it would interfere with the deep sleep reset circuit that I found more important.

One simple change from the nodeMCU design is that I swapped the USB Micro-B connector for a Type-C connector which requires a bit more PCB routing to deal with the reversable plug and two extra resistors to make it up to USB spec. The Type-C spec requires a 5.1kΩ resistor to ground on both CC pins (individually, don't cheap out and connect both CC pins to the same resistor like on the Raspberry Pi)

Most of this design work is simply reading the datasheets for the components and following the recommendations there. Some datasheets even have bits of recommended PCB layout in it to make the PCB layout easier.

Since all the complicated ESP8266 circuitry is already handled on the SoM I used and the USB-to-serial converter is laid out, the rest is simple connectors. Except... there's power stuff to deal with.

Most of the difficulty with this design is figuring out the power design. If the battery connection was not included it would've been relatively straightforward. Just have a power regulator that converts the 5V from the USB connector to the 3.3V for the rest of the board. This is exactly what the nodeMCU board does.

In my case the regulator has to deal with power coming from either USB or a single Lithium bringing the input voltage range from 3.4-ish to 5V. There's also a charger chip included to charge the connected cell and a bit of circuitry to switch between the battery and USB power.

The block diagram for the sensor board

The diagram above shows the final power design. It has the MCP1700 3.3V regulator to replace the LM1117 regulator from the nodeMCU design, the MCP part has a way lower quiescent current which helps with the battery life. The MCP73832 is a single cell li-ion/li-po charger that requires very few external components. In this design it's programmed to charge at 400mA which is not super fast but it should last some months on a single charge anyway.

The magic part is this circuit for the power switching:

This receives 5V from the USB connector or the battery power (or both) and feeds them into the regulator to generate the 3.3v rail. The MOSFET will disconnect the battery power when 5V is supplied and the diode makes sure that the power of the battery won't ever flow back into the 5V part of the schematic.

Since there's also a single analog input on the ESP8266 I thought it would be a good idea to use it to read the battery level. This is yet again a decision that added a bunch more complexity. The theory for this is pretty simple: you add a resistor divider to bring the 0V-4.3V of the battery to the 0V-1V range of the analog input and then you'd read the battery voltage with a bit of code. The issue of this is that the resistor divider will not only do the voltage scaling for the ADC but will also be a path for the battery to leak power.

This is the part that's added to fix that. With a few extra parts the resistor divider can be completely disconnected from the battery stopping the power leakage. The software on the ESP will have to first enable the measuring circuit by toggleing a gpio, reading the value with the ADC and then disableing the gpio again. Since there's already 5.1kΩ resistors on the board I'm using another one here together with a 100kΩ. This re-use of resistor values is done since some manufacturers charge extra per distinct part model used. This brings the voltage range of the battery down to about 0-0.2v. This seemed fine at the time since the ESP has a 10-bit ADC.

With using only a fifth of the ADC range the ADC resolution is already brought down to slightly less than 8 bits. But batteries usually don't go down to zero volts. The normal voltage range is 3-4.2V giving a voltage difference of 0.06V after the voltage divider making the result slightly less than 6 bits of resolution. This does not account for ADC noise in the system yet. The result is that the final battery level graph is a bit choppy but at least it functions.

The last thing left is connectors. I added a footprint for some screw terminals for the OneWire connection. This footprint is basically the same as a pinheader except it has a fancy outline. For the battery I added a JST-PH connector because it seemed the most common one for batteries.

The I2C and SPI bus don't have standardized connectors though. But, through a bit of searching I found the pmod spec. This is an open specification made by Digilent to connect modules to their FPGA development boards. It's perfect for this usecase since the interface is just pinheaders with a defined pinout and it defines the power supply as 3.3V which I already have on the board. Some of the sensors I want are even available as pmod modules.

The two pmod headers on the board

Getting the boards made

After laying out the PCB another complicated process begins. Getting it actually fabricated and assembled. The board has been designed that it can be hand-soldered if needed. No BGA parts are used and the _handsolder variants of the footprints are used for the common parts, which are slightly larger.

To not have vendor lock-in the board is designed to be assembled by both JLCPCB and Aisler. JLCPCB is the very cheap option in this case and Aisler is quite neat since it's actually in The Netherlands. The Aisler design rules are less forgiving than JLCPCB so I used those for the board. It mostly mean that I can't use the absolutely tiny vias that JLCPCB can drill.

For the assembly service metadata has been added to the schematic. For JLCPCB a LCSC column was added to the part data that contains the part code for ordering from LCSC. For Aisler the parts come from the other big parts warehouses instead like Mouser. For that the MPN column is added that contains the manufacturer part number.

With this data and the selected footprints the board can be assembled. I left out all the part numberes for the through-hole parts since those are either more expensive or impossible to assemble and also pretty easy to solder manually if required on that specific board.

To actually get it made Aisler has a nice plugin for the PCB editor in Kicad: Aisler Push. With this it's just a single button and the Kicad file will be sent off to Aisler where their servers will generate the necessary fabrication files from it. From there it's using the Aisler website to fix up the MPN matching with actual parts from various suppliers and pressing order.

For JLCPCB the process is more complicated. The fabrication files have to be generated manually. There's a tutorial for going through the various steps of generating the ~10 files you need and then those can be zipped up and uploaded to the website. Since the LCSC part codes are completely unique the assembly step of this process Just Works(tm) without having to adjust anything on the website.

If Aisler had an option to specify the exact part match in the schematic metadata instead it would probably be the easiest option in this case so I hope that gets figured out in the future. Two weeks later I had the board :)

The Firmware

For the firmware of this board I just re-used the one I had previously written for one of the nodeMCU based sensor boards and extended it for the sleep features. It's pretty basic firmware that does the standard WiFi connection things for the ESP module and connects to my MQTT server to push the sensor readings in a loop.

For the battery operated boards that wouldn't be enough though. With that firmware the battery would run out in hours. There's a great series of blog posts from Oppoverbakke that go into great detail on how to optimize deep sleep on the ESP module. Especially the last post on avoiding WiFi scanning is very helpful for reducing power use.

To avoid as many delays as possible the WiFi accesspoint mac address and channel are saved into the memory of the RTC inside the module which is the only part of the chip left powered in the deepest sleep mode. Then with that information the module will save around one second of time being awake and connecting. Another optimisation is using a static ip address instead of DHCP to save another second.

I don't like having static ip addresses in my network. I have static DHCP leases for everything instead. This is why I extended the RTC connection code to do a DHCP request the first time and then save the received DHCP data in the RTC memory together with a counter to re-do DHCP after some time. This means that my board is still a fully DHCP compliant device without making a DHCP request every time it wakes up, this is what the lease time is for after all. Thanks to this I only have to power down the board when I need to change the IP address instead of reflashing it or building in some configuration web interface.

During deep sleep the whole board uses 19.1µA with a half charged battery in my tests and the transmission is down to to a bit less than a second at 70mA, but the power use of the transmissions varies quite a lot.

I had one module in production outdoors quickly to test. It sleeps for one minute in deep sleep and doesn't have any other optimisations. Looking at the data from that module it looks like it would last for about two weeks, even with the sub-zero temperatures during the night.

The battery life for the optimized version has yet to be seen. I have calculated it to be around 3 months but it would take a while to have conclusive results on that. This board uses a "3500mAh" 18650 cell which I assume in the calculations is actually 2000mAh.

Next revisions

During testing and programming I found out I had made a few mistakes with the board design. The most problematic one is that I put zener diodes on the UART lines between the USB-to-serial converter and the ESP module. This was to prevent power from the serial lines to flow into the CP2102 module and powering up that chip partially.

This did not work. When I got the boards I spend a bit of time figuring out why the programmer couldn't connect. The voltage drop through the diodes I picked is probably too much for the serial communication to work. To make things worse the diodes are completely unnecessary for this since the uart lines won't leak power in deep sleep anyway. Luckily this is easily fixable on my boards by making a solder bridge across the diodes.

Another issue on the board is that the battery charger chip gets very hot and is too close to the temperature sensor. I also forgot to add the thermal relief specified in the layout suggestions of the part so while charging that chip is practically constantly at 80°C making the value of the temperature sensor raise by around 5°C. Since this only affects the board when the battery is charging it's not a critical fault.

For cost optimization I skipped battery protection on the board. For my uses I just ordered a protected 18650 cell so it should be fine. But since I'm making a second revision board to fix these issues anyway I decided to include a battery protection chip this time around.

The protection chip sits between the ground terminal of the battery and the actual board ground and disconnects the battery pack in case of overcurrent, short circuits, overcharge or undercharge.

Another small change I did is add an extra pinheader to the board to access the UART lines directly, since pinheaders are basically free anyway.

You should make your own boards

Making boards is fun. I learned a lot during the process and now have some important skills to use in my other projects. Can you really call yourself a full stack programmer if you haven't designed the hardware yourself? :D

Reverse engineering the BMD camera HDMI control

Martijn Braam — Thu, 09 Sep 2021 21:32:01 -0000

I have a Blackmagic Design 4k camera here (the bmpcc4k) and it has an interesting feature where you can control camera settings when hooking the hdmi cable from the camera to a BMD Atem mini series video switcher. It allows controlling a few settings that are not accessible in the camera settings itself like the values of the primary color corrector.

This is the exact same thing that their more expensive cameras for studios can do by hooking up a SDI (video over coax) cable to it and hooking it into a more expensive ATEM switcher.

The camera also has Bluetooth control which allows you to change some basic settings like resolution, audio settings and lens control. I have been able to use this but unfortunately I ran into a hardware defect where the touchscreen on the camera just stops working. At this point I did not have bluetooth switched on so I cannot even change my camera settings through that anymore. While this is a defect in the camera looking at the forums BMD did not really want to help with getting this fixed unless I pay a lot to get this fixed.

The alternative is figuring out how the HDMI control works, figuring out how much more is possible over that protocol and try to enable bluetooth through that.

Guesses

So the camera is controlled over the same HDMI connection that's used to feed the signal to the atem switcher. This works even with the cheapest cables I have and cable manufacturers love reducing the amount of wires in their cables. This doesn't leave a lot of option where that data can be. All the high speed data pairs in HDMI are directional and are going in the camera->switcher direction so it's not using anything complicated inside the HDMI frame to get data across. Looking at some pinouts this basically only leaves the CEC and DDC stuff.

DDC is the display data channel, it's an i2c bus that's used to query the information about the monitor that the cable is plugged in to. This exact same system is present in VGA, DVI, Displayport and HDMI. I guess the standard was good enough that it was just copied over to every newer one :)

Sniffing the DDC traffic

Messing with the DDC bus is usually pretty simple. On linux you can load the i2c-dev module and that will expose the DDC connections on all video outputs as /dev/i2c-* nodes. If I have my computer hooked into the HDMI input of an ATEM switcher I can dump the edid data over the bus using i2cdump for example:

# Bus 1 is my HDMI connector, 0x50 is the i2c address for the EDID eeprom
$ i2cdump -y 1 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 23 01 00 00 01 00 00 00    ........#?..?...
10: 26 10 01 03 80 47 28 96 0a da ff a3 58 4a a2 29    &????G(???.?XJ?)
20: 17 49 4b 00 00 00 01 01 01 01 01 01 01 01 01 01    ?IK...??????????
30: 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c    ???????:??q8-@X,
40: 45 00 c4 8e 21 00 00 1e 02 3a 80 d0 72 38 2d 40    E.??!..??:??r8-@
50: 58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 42    X,E.??!..?...?.B
60: 4d 44 20 48 44 4d 49 0a 20 20 20 20 00 00 00 fd    MD HDMI?    ...?
70: 00 32 3c 1f 44 08 00 0a 20 20 20 20 20 20 01 f7    .2<?D?.?      ??
80: 02 03 1f 54 49 85 84 94 93 a0 a1 a2 9f 90 23 09    ???TI?????????#?
90: 04 07 83 01 00 00 68 03 0c 00 10 00 00 1e 00 01    ????..h??.?..?.?
a0: 1d 00 72 51 d0 1e 20 6e 28 55 00 c4 8e 21 00 00    ?.rQ?? n(U.??!..
b0: 1e 01 1d 00 bc 52 d0 1e 20 b8 28 55 40 c4 8e 21    ???.?R?? ?(U@??!
c0: 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00    ..?.............
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2    ...............?

Doing the same for the camera is a lot harder though. Since the direction for that is reversed the computer has to be i2c slave on the hdmi connector instead which is not something that's just easily doable.

The other option is just splicing into the HDMI cable and finding the right wires. So that's exactly what I did.

The answer for "how to get the shielding off like this" is: carefully

After removing a part of the outer isolation and shielding from an HDMI cable it looks like there are a bunch of high speed differential pairs with individual shielding. Those are not interesting for the data I'm looking for, they will be the clock pairs and a pair for red, green and blue pixels (or YUV in some modes). Besides those pairs there are 4 wires left over and a ground wire.

DDC needs two wires to work, SDA and SCL for data and clock, and it needs the ground wire. The other two wires might be the +5V wire that was originally intended to power the EDID chip when the monitor is off. And a wire for hotplug detection of the connector. Since I don't care that much for the signal integrity of the cable, and these wires carry slow signals. I just decided to cut them and splice in some leftover resistor leads to heave points to attach probes to.

Then I just connected probes to these wires and hooked it up to a CWAV USBee AX 8 channel logic analyzer. With that connected and the wire colors correctly labeled I ran a 10 second dump in the sigrok pulseview software and plugged in the camera.

This was not what I expected. None of this looks like i2c data since there would be a clock and data pair. After looking at the HDMI pinouts some more I realized my mistake. There's 5 differential shielded pairs in my cable, one of them is used for the DDC data pair. But then what is happening on D4?

One of the other busses in the HDMI cable is CEC, the Consume Electronics Control signalling. This is used to send commands from your TV to a set-top box or DVD player. Instead of being a two wire bus this is a single wire bidirectional signalling system that follows the AV.link standard. Let's label that wire and see what Pulseview can decode from it.

Here is the view with the CEC decoder added and zoomed in on the initial little blip of data on the CEC wire. So what's happening here?

The bottom row of the decoder shows the actual highest level decoding of the bits, in this case it's 2x the same message. CEC uses 4 bits for addressing and the first byte of a packet contains the sender and receiver address. The blue "EO..." bit in this screenshot is the End Of Message byte which is true in this message indicating there's no more data for this frame. A frame with only the addresses is a PING command as indicated by the decoder. This is a message send by the device on power-up to check if a device at address 1 (Recording_1) already exist on the bus. If such a device exists it will pull the CEC line down directly after the EOM bit. In this case that didn't happen which results in the NACK bit at the end of the message.

So what's happening here is that either the camera or the switcher is checking the CEC bus to see if the address it wants to use already exists and not getting a ping response 2 times.

So the next message:

So here device 1 is sending a broadcast (destination 0xF) and it contains 3 more bytes of data. This means the second byte (0x84) is the opcode. In this case it's REPORT_PHYSICAL_ADDRESS and the last 2 bytes are the arguments for the command. There seems to be 2 addressing systems in CEC, the 4 bit address that's used for routing packets and a physical address, and this is the device at CEC address 1 broadcasting that it's physical address is 0x20 which decodes to address 2.0.0.0. The camera is connected to port 2 of the atem, if I move it to port 4 it becomes 4.0.0.0.

The the next command is a vendor command, so here the guessing starts again. the 0xA0 opcode that means the next 3 bytes are the vendor ID and the rest is the vendor specific command.

The 0x7c2e0d that's received after that is the mac OID for Blackmagic Design, so we're getting somewhere at least with this. Then the next bytes are 0x01 and 0x01. Now the hard part is figuring out what that means.

BMD vendor commands

So I found that by connecting a raspberry pi to the atem switcher I can monitor the CEC traffic it gets. Sadly it doesn't get a copy of all the CEC traffic happening in thee switcher as the standard says it should do. It does get CEC broadcast data instead.

From a quick look at some atem features that causes broadcasts to all devices, the first byte of the vendor data is a command ID and the rest is the argument. Command 0x03 is used to start/stop recording on all attached hardware where the first argument is 0x01 to start and 0x00 to stop.

Command 0x02 is the tally status command with the bytes following it being a bitfield for the tally. From a 4 port atem mini:

The program/preview controlled by the hardware panel:
Program 1, Preview 1: 0x03 0x00
Program 2, Preview 2: 0x30 0x00
Program 3, Preview 3: 0x00 0x03
Program 4, Preview 4: 0x00 0x30

Seperate program and preview tally:
Program 1, Preview 3: 0x01 0x02

So the data for this command is 2 bits per input, 2 bits wasted. The whole thing is little endian.

So my protocol docs so far:

cec vendor command	command	args	notes
0x1f 0xa0 0x7c2e0d	0x01	1 byte	unknown
0x1f 0xa0 0x7c2e0d	0x02	4 bits per channel	Tally status bit 0 is preview bit 1 is program bit 2 and 3 are reserved
0x1f 0xa0 0x7c2e0d	0x03	1 byte	Trigger record 0x00 = stop 0x01 = start

Interestingly, from sniffing the HDMI cable it looks like the color shading commands for the camera don't use the cec vendor command but they use just random (as far as I can tel) CEC opcodes. I have not been able to find just a list of CEC opcodes and their arguments so I can't really verify this. The CEC decoder in PulseView also doesn't seem to support all opcodes.

Camera control commands

addr	opcode	args	notes
0x01	0x19	?	Lift W
0x01	0x19	?	Lift W
0x01	0x1e	?	Saturation
0x01	0x1d	?	Hue
0x01	0x20	?	Contrast
0x01	0x42	u16	Aperture
0x01	0x46	i16	Zoom
0x01	0x52	i8	Gain, signed byte 0xf4 = -12dB
0x01	0x54	u8	White balance 0x32 = 2500k, 50k per step
0x01	0x55	u8	White balance tint Unknown format
0x01	0x57	i8	Shutter

So this is a list of a few of the full CEC packets sent when shading a camera, some of the signed values are a bit weird, becoming 2 bytes when they are negative and 1 byte when they are positive. Here's the contrast message for example:

Most of these controls don't have a neat numeric value to compare against in the ATEM Software Control software so to get the exact encoding it would be required to implement that in OpenSwitcher first.

Also to figure out the commands that are not implemented yet in ATEMSC I need to find a way to inject CEC commands between the camera and the atem. There's some USB solutions that might work, it's also possible with an arduino and a HDMI breakout. In either case I need to wait for parts so that will be a part 2 of this series.

With the protocol decoded it would be possible to do a few neat things, like make a cheap (and I mean really really cheap) injector to put between the network and the HDMI cable of the camera to remotely shade one of these cameras when you're not on the ATEM mini hardware but on the older generation of hardware instead.

Making a backcover extension for the PinePhone

Martijn Braam — Fri, 31 Jul 2020 10:16:41 -0000

So one of the features of the PinePhone that hasn't seen much (any?) use is the pogo pin expansion header on the back. It's 6 pogo pins that can be used to make backcovers that extend the phone functionality.

These pogo pins give external access to battery power, usb power, a dedicated i2c bus and an interrupt pin. This is enough to make a wide range of custom attachments. The official announced attachments are a battery extension backcover (that uses the two power pins) and a keyboard backcover (that uses the i2c bus).

Making your own extension

Since this is an open platform, it's quite easy to make your own extension that connects to the PinePhone pogo pins. In my case I'm going to attach an MLX90640 far-infrared thermal array, which is a fancy way of saying thermal camera. It's a module that can be get relatively cheap, but it's low resolution. The sensor only has 32x24 pixels, to get a good image that has to be upscaled and combined with a visible light camera (which conveniently is built into the PinePhone) to create a nice thermal image.

To make the physical interface, I melted 6 holes through a PinePhone backcover and put tiny nails in them that match up with the pogo pins.

I didn't have 6 nails of the same size ofcourse

I also made a video showing me doing this. Then I used some double sided tape to stick the thermal camera module to the backcover and soldered wires between the sensor and the nails. The pinout for the pogo pins is this:

Connecting up an i2c device should be relatively straightforward, it's important to note that the i2c lines are pulled up by the phone to 3v3.

The VBUS pin is powered by USB, I used this one for the sensor, it only has power when something is plugged into USB, and it's 5V.

The second power pin is VBAT, which connects to the battery voltage.

What can you do with this?

Everything! The sky is the limit! except bandwith and power constraints ofcourse...

The maximum speed of the i2c bus is 400 kHz, which is enough for a lot of applications, but don't expect to add ethernet or hdmi to this. Since i2c is a bus you can add multiple things at the same time to these pins. I just added the single thermal camera but you can just add a second i2c device to the same pins in parallel.

If you need another bus than i2c you can probably get a bridge chip for it or add a small microcontroller to bridge another protocol. Basically any microcontroller has support for i2c and can most likely connect to whatever you want, like use gpio on the microcontroller to read from a keyboard matrix, or add some IR leds and sensors to add IrDA.

The software side

There are two ways to use your newly attached gadget. The first is i2cdev. It isn't super efficient but it gives you access to the i2c hardware directly from userspace. The only thing that's needed is modprobe i2cdevto make /dev/i2c* appear. The bus on the pogopins on the PinePhone is twi2, so /dev/i2c-2 should be the right bus.

Here's a simple python example for reading a byte from and attached i2c chip:

from smbus2 import SMBus

# Connect to /dev/i2c-2
bus = SMBus(2)

# Read register 0x42 from the i2c device at address 0x33
bus.write_byte_data(0x33, 0, 0x42)
value = bus.read_byte_data(0x33, 0)

The second method is letting a kernel module deal with the hardware. This can be accomplished by recompiling the dtb/kernel with your hardware in it, which isn't very portable. Or by using device tree overlays.

Here's an example of the dtbo for an TI HDC1000 humidity and temperature sensor:

// Definitions for dhc1000 module
/dts-v1/;
/plugin/;

/ {
fragment@0 {
	// Target the pogo pin i2c bus
	target = <&i2c2>;
	__overlay__ {
	
		// Define the hdc100x device on this i2c bus
		hdc100x@40 {
			compatible = "ti,hdc1000";
			reg = <0x40>;
		};
		
	};
};

The loading of this device tree overlay is more complicated. It needs to be compiled first, which needs the sources of the kernel used on the PinePhone so it knows what &i2c2 means. Then the compiled dtbo file needs to be put somewhere in sysfs to make it load at runtime, or needs to be added to u-boot to be loaded at boot time. This is all a bit out of scope for this article (meaning I haven't tried it yet)

After the dtbo is loaded, the new device should just show up in the kernel like it was always part of the phone, in this example it's an iio sensor so it shows up in /sys/bus/iio/device:$number/$parameter, so you can just query the humidity by reading some file.

Connecting a thermal camera

One of the things I have had here in my parts bin is the MLX90640 thermal imaging sensor. I thought it would make for a great demo of what's possible with the pogo pins. Connecting it was trivial since it only needs power and i2c on the breakout board I have and this breakout board also has a voltage regular so I can power it by anything from 3 to 6 volts, perfect for the PinePhone.

For the software side I chose the i2cdev method and used python to get data from the sensor. Only after a while I found out that there's already a kernel module available in the mainline kernel that exposes this sensor as a regular v4l2 webcam.

The first python lib I tried was the Adafruit circuitpython one, I didn't manage to get this to work since it expects if you're running it on Linux that it's must be a raspberry pi. Then I found a module from Seeed studio which seemed easier but still didn't give me any data from the sensor after messing with it for a while. It turns out the seeed and adafruit code is very similar and probably copied from eachother and had the interfacing code replaced.

Since both libraries weren't working I wrote a quick 'n dirty python script based on the registermap in the datasheet of the sensor and managed to get the raw sensor data from that. This code doesn't read the factory calibration data yet from the sensors eeeprom so there's quite a lot of variance in the pixels. The raw data from the pixels is also 16 bit signed data, which I just pick the 8 most significant bits from to make a simple grayscale png as output. Since somewhere around room temperature these raw values go negative there's some pure white pixels instead of useful data.

Left: raw pixels, top right: properly interpolated and upscaled, bottom right: more familiar color map applied

The raw data from the sensor looks a bit underwhelming, it's mainly messed up by not applying calibration which should get rid of the checkerboard pattern and the data format which should get rid of the white pixels.

The sensor actually responds with 2 extra rows of "pixels", this data is the extra data needed to get proper measurements from this like the global gain of the chip (since it does auto exposure) and the ambient chip temperature. With that data the absolute temperature for every pixel can be calculated.

For getting real nice "FLIR-like" output from this it should also be combined with the image captured from the way higher resolution normal camera in the PinePhone itself.

Conclusion

Is this demo practical? not really, the camera works but since it's quite bulky the phone can't be put in your pocket anymore. This can probably be solved by using a 3d printed backcover instead that properly integrates the camera and keeps it aligned with the visible light camera. This also needs a lot more software work to make it a nice experience.

It does provide a great demo of the extendability though and I can't wait to see what people will do with this feature.

E-paper status display

Martijn Braam — Mon, 27 Apr 2020 18:00:00 -0000

There's a project called LCD Smartie that converted a character LCD into a small status monitor for your computer. It can show system status, the info on what's playing in Winamp. E-mail headlines.

LCD Smartie example (from lcdsmartie.sourceforge.net)

I wanted to have something similar, but connected to my fileserver to show some stats, but I didn't want to have yet another permanent light on my desk, it's already a chrismas lightshow of blue, green and orange power and status lights for various devices.

The nice solution for this would be using an e-paper display instead of an LCD. After some searching I found the 6" display kit with raspberry pi hat from Waveshare.

The kit with an image uploaded through the Windows software

The nice thing about this specific board is that it also has a microUSB port for connecting it to a computer instead of a raspberry pi. Sadly there isn't really a lot of information available about this interface, it's designed to be driven by spi, i2c or i80 and the docs reflect that. The USB port seems to be mainly for updating firmware.

Waveshare has a Windows tool available that can communicate with the display controller over USB and upload firmware, it can also send images to it with their clunky interface. I want to control it with Linux though so I have to write something new.

The USB interface is pretty weird. The display shows up as a mass storage device with no medium inserted (like an SD card reader with no card inserted). Somehow their software can communicate with this. So the first step is sysinternals procmon. This is basically equivelent to running a strace in Windows.

This shows it's opening the virtual mass storage device from the display controller (F: in my case) and then using IOCTL_SCSI_PASS_THROUGH_DIRECT to actually control the display.

This is the same communication protocol used by tools like smartmontools to communicate with harddisk firmware to get disk information. So the upside is that it should be possible to control this display without messing with kernel modules. The downside is that it will require root to control the display.

With this information I was finally able to find a datasheet that had some details on the USB communication protocol called "IT8951 USB Programming Guide" This contains some details on how the protocol works and some demo code for making these calls in Windows. Armed with this information I started writing a C program that should draw to the display.

The drawing procedure is pretty simple. You send a command to get some general information like the resolution and the address of the framebuffer. Then you use the load image command to send pixels to a specific part of the framebuffer, then you use the display command to actually trigger the display refresh. This is the part that makes the display flicker and show the new content.

It was all pretty straightforward except that it didn't work. My display just didn't start flickering to update the contents. After scanning through the datasheet for a while I gave up and went back to reverse engineering the Windows tool. This time I used Wireshark to make a dump of all the USB traffic since procmon didn't show me the actual data in the syscalls.

This did show some interesting things. Mainly that I was missing a single byte in the display update command (0x94) causing the display controller to hang until it was reset. Another interesting thing I noticed is that for uploading a full-screen image (800x600) it was sending the image in strips of 800x76 pixels using seperate load-image commands and then sending a single display-image command to update the whole screen. After implementing this I was able to update my e-paper over USB from Linux!

All this is available as a simple small tool: it8951 (named after the controller used). It takes a device name, x+y coordinates and the image width,height to update on the screen and then takes raw image data on stdin to display. The nice thing about this controller is that you don't have to care at all about low level image formatting, just send a 8-bit grayscale image to it and it will be converted in the right format to the display.

This display supports multiple modes (selected by the -m argument of my tool). Mode 0 is used to completely blank a region. It will flicker a few times and then make the region perfectly white.

The next one is Mode 2, it will display a 16 level grayscale image based on the 256 level input image you gave it, it will not do any dithering for this. Updating the screen in this mode will cause it to flicker that region once. This is called G16 mode.

The other nice mode is Mode 4, it is called A2 mode and will update the screen without flickering. It is very fast but it has a downside, it only renders pure black and white.

The date is drawn in G16 mode and the time in A2 mode

In the example above the date is drawn in G16 mode, since it's not updated often anyway and the time is drawn in A2 mode so it can update every minute without having an annoying flicker. You can see that the date has smoother edges since it can be anti-aliased using the 16 grayscale levels, The time has crispy edges since it's only pure black. Also the A2 move leaves some ghosting behind as you can see.

Drawing something useful

Now I have the display working with a tool I can pipe data into I made a python program that uses PIL to generate a nice status display. It generates a full screen background image that has the dates and the borders on them and draws that every day at midnight with a fresh date. It also uses this moment to fully clear the display in mode 0 to get rid of ghosting artifacts. Then it will update the time every minute in A2 mode in the center. It will then check all the data feeds and if one changed it will update only that specific region in G16 mode, which is distracting, but at that point it will also notify you that there's new data. When the python script is restarted it will update all the regions one by one, which looks very satisfying.

The next step is making a nice wooden frame around it so it can stand on my desk.

Harley Benton (Thomann) Power Attenuator test and teardown

Martijn Braam — Fri, 26 Feb 2016 23:00:00 -0000

Thomann just started shipping their new Harley Benton Power Attenuator. It can handle an input power of
80 watts (it contains an 100 watt L-pad, so they added some margin). It is a simple device containing
only passive components. It has a control for cabinet volume and line-out volume but they are not fully
seperated. The line-out level is a signel tapped of after the main cabinet volume knob so you can't
turn the cabinet completely off and use the line out for recording / headset usage.

Measurement

To measure the performance of the attenuator I connected it to a USB DAC/ADC and ran a frequency sweep with the
tool QLoud. QLoud is a tool normally used to measure the frequency response of a speaker using a measurement microphone.

I connected the line out signal of the DAC to the 16 Ohm speaker input of the attenuator and connected the
speaker output of the attenuator to the line in of the USB DAC. I also did a reference measurement by
connecting the input and output of my DAC/ADC directly together. The last set of measurements is connecting
the line signal to the input of my guitar tube amp (a Defender 5H 15 watt all-tube amp) and connecting the
line-out of the attenuator to the USB ADC.

Taking it apart

I'm also curious what is inside a fully passive device for ~100 euro so I took it apart. The case is
very easy to open, 4 screws on the front and 4 on the back and you can just lift the side and top part off.

The answer to my question: there is not a lot in it.

The main part of the attenuator is the 100 watt L-pad (The huge potentiometer behind the cabinet volume knob).
The signal from the amp is put almost directly accross the two outer pins of the potmeter so it will dissipate
most of the energy. The other large part of the circuit is a bunch of 50 watt resistors (The resistors with
orange cooling fins). They are there to match the impedance for the amp. The signal coming from the L-pad pot
and the small potmeter for line-out is put straight into the line-out and speaker-out jack on the PCB. The rest
of the circuit on the PCB is for the MicMod circuit that is supposed to simulate a cabinet and provide a balanced
microphone signal. I haven't tested the MicMod output yet.

Yeah, I'm not so great with CAD software

Modding a Behringer VT911

Martijn Braam — Sun, 03 May 2015 22:00:00 -0000

A few weeks ago I replaced my Line6 Podxt live multieffect pedal with a guitar amp, cabinet and 2 pedals.
The amp is a Kustom Defender 5H head and I use a Kustom 1x12 cab with it.

To replace the multieffect pedal I bought a Behringer VT911 overdrive pedal and a
Digitech Digital Reverb pedal. I chose for the VT911 because it contains a tube for the distortion and it
only cost me € 14,90 at Thomann.

The pedal sounds fine. Not great but it's a great pedal for the price. I searched on the internet
for easy mods to do on the pedal to improve the sound quality and found various suggestions on a few forums.

The first thing I did was adding a resistor and capacitor to the tube board to give the tube some extra
headroom. One of the major problems I had was that it doesn't really have a setting to only distort a little.
In the 0-1 range on the overdrive the pedal is usable but is very quiet even with the volume all the way to 10.
On the 1-10 range the pedal distorts so much that I wouldn't call this a overdrive pedal anymore.

The mod on the tube board increases the headroom so the tube distorts later and has a lot less compression
but the drive knob doesn't have a very large usable range. On the high distortion range the pedal also
starts to sound very muddy. The second mod adds another resistor and capacitor parallel to the drive potmeter
to change it's range and frequency response.

Here is a list of the exact values used in the mod:

Tube board:
  4.7 nF capacitor between pin 1 and 7 on the tube (marked 472)
  470 ohm resistor between pin 7 and ground (yellow purple black black brown)

Main board:
  1.0 nF capacitor connected to the outer pins of the drive pot (marked 102)
  100 Kohm resistor parallel to the same pot (brown black black orange brown)

I've recorded a sample before the mod and after the mod. Judge for yourself:

Bus Pirate V3 and LM75 temperature sensors

Martijn Braam — Sun, 20 Jul 2014 22:00:00 -0000

This is a tiny reference for reading the temperature with an LM75a temperature sensor and a Bus Pirate v3 on a Linux computer.

What is a Bus Pirate

The Bus Pirate is a "hacker multi-tool" developed by Dangerous Prototypes. The tool is basically an interface between your computer and a lot of standard communication busses like: spi, i2c, 1-wire, JTAG, uart, midi and ps2-keyboard. It also has a frequency counter (1Hz - 40Mhz) and generator (1kHz - 4Mhz), a low speed logic analyzer (10Hz - 1Mhz) and a lot more. You can read more about this on the features page

What is an LM75

The LM75 is a small temperature measurement chip mostly used inside computers. The Linux tool lm-sensors has built-in support for LM75 temperature sensors connected to an i2c bus supported by Linux. This makes it possible to connect the LM75 temperature sensor to a usb to i2c bridge and connect environment temperature sensors to Linux and use it to control internal and external fans.

The product page for this chip lists the accuracy as 2°c and the accurate range as -25°c - 100°c. Whats unlisted is that the precision of the chip is 0.125°c so if you calibrate the chip with a good thermometer you can measure the temperature in way smaller steps.

Connecting the sensor

The sensor is in a small package so I used a breakout board for easier connecting.

My connections:

Bus Pirate | LM75 | Name
-------------------------------------------
red        | VCC  | Bus Pirate +3.3V source
green      | VCC  | Bus Pirate pull-up voltage
brown      | GND  | Ground
grey       | SDA  | i2c data line
purple     | SCL  | i2c clock line

The exact pins on your LM75 depend on the package. Check the datasheet

Firing up the Bus Pirate

After you connect the Bus Pirate to the computer there should be a new ttyUSB device available. (check this with the dmesg command). The easiest way to use the Bus Pirate is to connect to it with screen. To do this run the following command:

$ screen /dev/ttyUSB0 115200
# if you get a permission issue try:
$ sudo screen /dev/ttyUSB0 115200

After connecting press enter and the Bus Pirate prompt should appear (HiZ>). This prompt means its currently in HiZ mode. To switch the mode press m and press enter. Then enter 4 (i2c). Then it asks for the speed. The LM75a can operate on any i2c speed up to 400Khz so choose any.

After switching to i2c mode the prompt is changed to I2C> now you need to enable the power supply and the pull-up resistors.

I2C>W
Power supplies ON
I2C>P
Pull-up resistors ON
I2C>

Now all the communications are initialized. The next command is dependend on the address of your LM75 chip. The address is set with the 3 address pins. if all address pins are grounded the address is 0x48. The Bus Pirate has a handy macro for finding all i2c slaves on the connected bus. Enter (1), something like this should appear:

I2C>(1)
Searching I2C address space. Found devices at:
0x92(0x49 W) 0x93(0x49 R)

This means that my LM75 is on the address 0x49 and it lists the send and receive address. To get the current temperature enter the following command:

I2C>[0x93 rr]
I2C START BIT
WRITE: 0x93 ACK
READ: 0x12
READ:  ACK 0x20
NACK
I2C STOP BIT
I2C>

This makes it write 0x93 to the bus (The read address of the LM75) and read 2 bytes. The two received bytes are 0x12 and 0x20. The most significant byte is sent first so that makes for a temperature of 0x1220 or 4622 in decimal. To get the real temperature divide this number by 255 and round to the nearest 0.125. This makes the read temperature 18.125°c Automatic reading

The Bus Pirate has a nice python api for automating communication called pyBusPirateLite. To read the temperature from my sensor I modified the thermometer.pyscript and created lm75.py.

#!/usr/bin/env python
import sys
from pyBusPirateLite.I2Chigh import *

class LM75:
    def __init__(self, i2c, address=0x48):
        self.i2c = i2c;
        self.address = address;

    def get_temp_reg(self, reg):
        temp = self.i2c.get_word(self.address, reg);
        if temp < 32768:
            return temp/256.0;
        else:
            return (temp-65536)/256.0;

    def get_temp(self):
        return self.get_temp_reg(0x00);

if __name__ == '__main__':
    try:
        # Serial timeout five seconds for debugging mistakes in I2C class
        i2c = I2Chigh("/dev/ttyUSB0", 115200, 5)
    except Exception, e:
        print "Error",e
        sys.exit()

    i2c.BBmode()
    i2c.enter_I2C()

    if not i2c.cfg_pins(I2CPins.POWER | I2CPins.PULLUPS):
        print "Failed to set I2C peripherals."
        sys.exit()
    if not i2c.set_speed(I2CSpeed._100KHZ):
        print "Failed to set I2C Speed."
        sys.exit()
    i2c.timeout(0.2)

    lm75 = LM75(i2c, int(sys.argv[1], base=16))
    print lm75.get_temp()

Run this command with the address of your LM75 sensor and you should get the current temperature

# Read from LM75 on address 0x49
$ ./lm75.py 49
18.125

Reverse-engineering a Logitech speaker set

Martijn Braam — Sat, 19 Apr 2014 22:00:00 -0000

Last week I received a broken Logitech 2.1 speakers set. The Logitech z-340 specificaly. The power light turned on but no sound and the volume knob produced a crackling sound when turning so the amp in the subwoofer is still working. I've tried disassembling the subwoofer but it's mostly glued together. So I first reverse engineered the speaker unit. It contains a small circuit board with the controls for the subwoofer. The left speaker and the subwoofer are connected with a 10 pin cable with din connectors. The speaker unit also contains a preamp for the headphones output

The reverse-engineered schematic

After some testing and probing on the circuit board I found out that the volume potentiometer is broken. I don't have spare stereo potentiometers lying around so I soldered two wires across it. Now the speakerset always run on full volume and I change the volume on my laptop.

After "fixing" the speakerset I found out that it sounds like complete crap. It has a very strong bass and a lot of treble but all the mid-tones are gone so I don't think I will be having this speakerset for long.