Computing stuff tied to the physical world

Archive for February 2009


Adding a µSD card

In AVR on Feb 28, 2009 at 00:01

Secure Digital cards are particularly simple to connect to, because they can be made to run in SPI mode – even the tiny µSD version. The SPI/ISP 2×4-pin header on a JeeNode has all the power lines and signals to do so:

Adding a µSD card

That’s a 2 gigabyte memory card, the size of a fingernail…

Enough storage capacity to “sniff” lots and lots of wireless packets from the airwaves. Just what I need to collect house measurement data of all kinds in a fully unattended manner, in fact.

In this case the hardware is actually the easy part. It takes much more work to read and write 512-byte blocks and to create a simple way to organize and access the stored data. I don’t really need a file system, just a robust way to log data and to play back selected parts of the stored data to another computer later.

Right now, all this does is identify the card and read and write 100 blocks:

Adding a µSD card

Looks like reading a block takes about 3.5 msec, writing one takes 41 msec. This is not a show-stopper, but with the µSD sharing the same SPI bus as the RFM12B, care will have to be taken to avoid dropping too many packets.


Out of spec

In AVR, Hardware on Feb 27, 2009 at 00:01

Running an Atmega168 at 16 MHz on 3.3V power is beyond its specs:

Out of spec

Officially, you’re only allowed to run it at up 13.333 Mhz with 3.3V. Easy math: it’s 10 Mhz change over a range of 1.8V, and 3.3V is one third of the way up from 2.7V.

Yet I’ve been running this chip with a 16 Mhz resonator on at least a dozen JeeNodes now. I don’t know whether that means all is well because the limits are conservative ones, or whether they might fail outdoors in an extended temperature range, or whether a few units will not work.

,

Memsic 2-axis accelerometer

In AVR, Hardware on Feb 26, 2009 at 00:01

Yet another sensor mounted on a breakout board by Parallax, is the Memsic 2125 accelerometer:

Memsic 2125 2-axis accelerometer

Demo sketch, called “accel2125_demo” in the Ports library:

Memsic 2125 2-axis accelerometer

Sample output:

Memsic 2125 2-axis accelerometer

The pulses are 5 msec at rest, and changed slightly when I moved this thing (rather gently).

Might work nicely for a self-balancing robot…

,

QTI measures reflection

In AVR, Hardware on Feb 25, 2009 at 00:01

Parallax offers a QTI sensor, which is a led + photo transistor on a breakout board. It’s easy to hook up to a JeeNode because the pin-out matches port pins 3..5:

A QTI sensor measures reflection

Demo sketch, added as example to the Ports library:

A QTI sensor measures reflection

Sample output:

A QTI sensor measures reflection

Could be used to count power / gas meter revolutions.


So what's with pins 1 and 6?

In AVR, Hardware on Feb 24, 2009 at 00:01

So far, I’ve only been using pins 2..5 on all ports:

So what’s with port pins 1 and 6, eh?

The main reason being that they offer most of what I need anyway: 2 I/O lines and power. The main idea of ports is that they include power alongside the I/O lines, which makes experimentation much simpler while also allowing me to reconnect stuff to different ports at will. It’s fascinating how much one can do with just the AIO + DIO signals.

Two more pins were added relatively late in the design process: the raw pre-regulator power line (PWR) and an open-collector interrupt line shared by all ports (IRQ). Some chips such as I2C port expanders have the ability to drive higher voltages and an option to generate interrupts. So one practical scenario is with +5V as PWR to support 5V sensors and other chips. Level conversion may still be needed for the DIO + AIO pins, but at least there is +5V to properly drive everything. An obvious source of 5V power is a USB port, so with the proper FTDI cable or breakout board PWR becomes a convenient +5V line.

As for IRQ: I’m a big fan of interrupts. They make it possible to handle tasks in the background, such as keeping a wireless connection going. Or responding to events without having to wait for them in busy loops.

But there’s a potential problem: external power is on pin 6, right next to +3.3V. If pins 5 and 6 ever get shorted out with +6V or more on pin 6, then this could fry the entire system: MPU, sensors, everything. It’s the same as shorting the input and output pins of the voltage regulator!

I’m considering switching pin assignments 1 and 6 for a re-designed JeeNode, i.e. PWR on 1 and IRQ on 6. At least that way everything but the MPU might survive such an accident. With expensive sensors, this matters.

For now, it’s best to use just pins 2..5 where possible.


Breadboard options

In AVR, Hardware on Feb 23, 2009 at 00:01

The JeeNode can be used with breadboards in different ways. The smallest configuration is a mini-breadboard, allowing one wire per pin (or 2, just…):

Breadboard options

To get more connections on each pin, use this:

Breadboard options

Or a bigger breadboard:

Breadboard options

Or use one breadboard per port:

Breadboard options

You could also set things up vertically:

Breadboard options

The rotated layout lets you switch between diagonally opposite ports, here are ports 1 and 4:

Breadboard options

The black and white boards can be swapped without having to redo any wiring:

Breadboard options

You can also flip entire sides:

Breadboard options

And finally there’s the option of using wire-wrap pins as IC socket to get access to all of the ATmega’s pins:

Breadboard options

Although that hardly qualifies as a JeeNode anymore…

,

All together now

In AVR, Software on Feb 22, 2009 at 00:01

It’s time to combine everything:

Combi demo

This is a setup with all the sensor interfaces documented in recent posts:

  1. a SHT11 to measure relative humidity (and temperature)
  2. a BMP085 sensor to measure barometric pressure (and temperature)
  3. PIR + LDR sensors to demonstrate reading digital and analog signals
  4. a Nunchuk with 2-axis joystick, 3-axis accelerometer, and 2 buttons

A new “combi_demo” has been added to the Ports library. The code is essentially the concatenation of the individual demo source files (you can browse the real thing here):

Combi demo

This example illustrates how the Ports library lets you mix and match drivers and ports at will. Note that two I2C interfaces are running in parallel at different speeds (sure, the BMP085 and the Nunchuk could also have been tied to a single port, running at 100 KHz).

Sample output;

Combi demo

This example compiles to 9114 bytes of code with the Arduino 13 IDE, so there is still plenty of room left to add, say, a wireless driver.

,

Hooking up a Nunchuk

In AVR on Feb 21, 2009 at 00:01

The Nintendo “Nunchuk” controller is for the Wii game console, but it’s also a great I2C input device. So for fun and as a game… I hooked one up to port 4 of a JeeNode:

Hooking up a Nunchuk

Although the “Wiichuck” adapter lets you connect an unmodified Nunchuk, I just ripped the whole thing apart, and cut off the proprietary connector. There are four wires, tied to pins 2..5 of port 4, respectively: green (SDA), white (GND), yellow (SCL), and red (+3.3V). The following “nunchuk_demo” has been added to the Ports library:

Hooking up a Nunchuk

Sample output:

Hooking up a Nunchuk

PS. I2C on port 4 = (on Arduino) SDA: D7, SCL: A3 (see JeeNode-v2.pdf page 3).

Update – swap the red and yellow wires for the JeeNode v3 and v4 (the above is an older unit).

,

Two simple sensors

In AVR on Feb 20, 2009 at 00:01

This is an example of hooking up two simple sensors to a single JeeNode port:

Two simple sensors

The Passive-IR (PIR) sensor by Parallax is on the DIO pin of port 3 (with ground and +3.3V also connected), and there is an LDR between the AIO pin and ground. Here’s sample code, as included with the Ports library:

Two simple sensors

Sample output:

Two simple sensors

,

Hooking up a BMP085 sensor

In AVR, Software on Feb 19, 2009 at 00:01

The BMP085 sensor measures barometric pressure (and temperature). I’ve hooked it up to port 2 via I2C:

Hooking up a BMP085 sensor

As SMD, it’s tiny …

Hooking up a BMP085 sensor

The 4 wire-wrap wires are connected to port pins 2..5, respectively: SDA (DIO), ground, SCK (AIO), and 3.3V power.

There’s now a bit-banging I2C master driver in the Ports library which works with any of the 4 ports, plus a new driver for the BMP085. Here’s the new demo code, now included with the library:

Hooking up a BMP085 sensor

It looks like the elaborate algorithm from the BMP085 data sheet to calculate pressure in Pascals (millibar) contains an error. After some guess-work and with information from the older SMD500 sensor, I think I’ve come up with the proper computations. The results are now as expected:

Hooking up a BMP085 sensor

This is a very sensitive MEMS sensor. It’s accurate enough in its lowest resolution mode to calculate altitude to 50 cm accuracy given the exact pressure at sea level – just moving the sensor up and down shows a matching variation! Higher-resolution modes have been not been implemented.

Update – There’s a problem with the calculations: with temperatures 25.0 °C and up, the pressure calculations fail and a result of 2.35 mBar is reported. Will need to look into this.

Update 2 – Thanks to a private email suggestion, I’ve finally been able to resolve the > 25 °C bug. The current source code no longer has the problem and shows consistent values also at higher temperatures.


A few more PCB's

In AVR on Feb 18, 2009 at 00:01

More JeeNode prototype PCB’s, from Olimex (longer shipping times):

A few more PCB’s

These have a gold-plated finish. Not sure how that compares with the other tin-plated ones – I’ve had issues with (dirty?) gold-plated boards once, which didn’t pick up solder as easily. But these look pretty sharp!

Slightly different board (e.g. mounting holes & via’s) – same electrical connections.

If you hook the JeeNode up to a 3.3V source such as this FTDI breakout board by SparkFun, then all the power supply parts can be omitted and the regulator pins can be bridged:

A few more PCB’s

And here’s a BAD idea:

A few more PCB’s

I’ve used wirewrap pins to “extend” the ATmega chip through this PCB, with only the radio module mounted. A quick test shows that the radio works, but this is running the RFM12B at +5V – well beyond its maximum design specs of +3.8V! Besides, you lose the main benefit of being able to add shields – all you get is a USB connection.

The PCB-POOL board was used because the IC socket holes of the Olimex board were too narrow to easily push wire-wrap pins through.

EAGLE schematic (PDF) & board files (jee-pcb-001).

,

Hooking up an SHT11 sensor

In AVR, Software on Feb 17, 2009 at 00:01

The SHT11 sensor measures relative humidity and temperature. It connects via 2 I/O lines using an I2C’ish protocol with a funny (optional) CRC check. I’ve hooked it up to port 1 on a JeeNode:

Hooking up an SHT11 sensor

There are just four wires to connect to this minute module. Here’s a close-up, with data and ground crossed over to port pins 2 and 3, respectively:

Hooking up an SHT11 sensor

The sensor is mounted free-floating on this little DIY breakout board so it picks up ambient air properties.

A driver for the SHT11 has been added to the Ports library, along with a small demo:

Hooking up an SHT11 sensor

A “sensor” object is defined at the top, tied to a specific “port” – the SHT11 class is derived from the Port class.

Sample output:

Hooking up an SHT11 sensor

The driver uses PROGMEM for the optional crc table. This causes a warning in Arduino-0013 when switching boards (which recompiles PortsSHT11.cpp), probably due to this issue, i.e. gcc bug #34734.

With thanks to Guido Socher for his excellent page about the SHT11 (his version does all calculations using fixed point integers, if you prefer to avoid floats).

Update – Changes checked-in and ZIP file updated. Thanks to Stephen Eaton for pointing out a mistake in the calculation constants for 3.3V.


Regulator pinout

In Uncategorized on Feb 16, 2009 at 00:01

Spot the difference:

Regulator pinout

… versus:

Regulator pinout

The regulator on the top is an LP2950-3.3, the regulator on the bottom is an MCP1702-33. Same voltage, same TO-92 package, different pinout. The board was designed for the LP2950, but the MCP1702 is cheaper and can supply more power (250 mA vs. 100 mA). Haven’t compared dropout voltages yet – if either one can deliver 3.3V from a 3.7 V LiPo battery or even from 3.6 V NiMh’s, then that would be a plus.


Remote ports

In AVR, Software on Feb 15, 2009 at 00:07

Yesterday was about local “ports” on the Arduino’ish JeeNode. Today, this is extended to remote ports. Here’s a sketch which controls ports wirelessly:

Remote ports

It’s almost like the local one, except for some headers and declarations at the top and a new “bob.poll()” in the main loop. Where “bob” is defined as the object representing a remote node with id ‘B’ (id’s ‘A’ through ‘Z’ are available for general use). Welcome to the world of messaging and transport independence.

This is a test setup with two JeeNodes:

Remote ports

The receiver (top) is powered by a 3x AAA battery pack (it turns out that 3x NiMh ≈ 4V). The transmitter (bottom) is tied to the USB port. This test sends 25 packets per second through the air (data + ack at 80 msec intervals). Probably OK for a quick test, but not for prolonged use!

This test setup makes it easy to check range by walking around with the receiver. Turns out that it’s just fine for my purposes: this works across 3 stone walls / concrete floors. Data rate is ≈ 57600 baud.

The changes to the Ports library have been included in the new Ports.zip release and in subversion, see also the previous post. Two new examples have been added: blink_xmit and blink_recv. The receiver code decodes and interprets each packet and performs all port I/O requested by the transmitter. Input values are then sent back in the ack packet.

The Arduino-0013 IDE compiles “blink_xmit” and “blink_recv” to 3128 and 2644 bytes, respectively. So there’s plenty of room for more functionality.


Ports library for Arduino

In AVR, Software on Feb 14, 2009 at 00:03

Here is a “Hello world” sketch for JeeNodes, luxury edition:

Ports library for Arduino

It drives 4 LEDs, one connected to each the DIO + GND pins of each “port”. The LEDs on ports 1 and 4 blink at different rates, while LEDs 2 and 3 use the PWM output capabilities to continuously light up and then dim again (like Macs do in sleep mode). Only ports 2 and 3 support PWM.

Here’s a setup using four 4-pin headers on a JeeNode with a mini breadboard (port pins 1 and 6 are rarely used). Note how ports 1 & 2 are rotated 180° w.r.t. ports 3 & 4:

Ports library for Arduino

Each of the LEDs is connected to port pins 2 and 3 with a series resistor. The red LED is port 1, then counter clockwise ports 2 (green), 3 (green), and 4 (yellow). The wireless isn’t being used in this example.

This uses a new “Ports” library which is available as Ports.zip or via subversion. This code needs to be placed in the Arduino IDE’s “libraries/” folder. It includes this “blink_ports” example.

My next post will explain why I went through the trouble of creating this Ports library. For now it’s just a thin wrapper around the standard pinMode(), digitalRead(), digitalWrite(), analogRead(), and analogWrite() calls.

Update – sources now in subversion.


It's called a JeeNode

In AVR, News on Feb 13, 2009 at 00:07

In case you missed that last image of my new Arduino’ish / wireless’ish design, here it is again:

It’s called a JeeNode

It’s simple, it works, and I hope it’ll become useful as building block for all sorts of tasks around the house. The previous post has all the details.

And now it has a name: I’m calling this a JeeNode.

I’ve also added a Projects page to this blog (near the top), to more easily find related posts.


Finished PCBs with RFM12B

In AVR on Feb 12, 2009 at 00:13

Here are the finished PCBs – my first steps on the road to custom electronics:

Finished PCBs with RFM12B

Component side at the bottom, with the radio SMD-like pads on the right.

This board is by PCB-POOL in Ireland. I omitted the silk screen for this first run. The board looks very well made, with a very clean and smooth outside border.

The big question of course is: is the board correct, will the circuit work?

Step 1 – resistor, IC socket, and ISP/SPI connector (actually, I also needed the 16 MHz resonator):

Finished PCBs with RFM12B

Step 2 – add ATmega168 and program the boot loader:

Finished PCBs with RFM12B

It works! (no errors)

Step 3 – add all 5 capacitors:

Finished PCBs with RFM12B

Step 4 – add 3.3V regulator and FTDI connector:

Finished PCBs with RFM12B

It works! (ASCIITable example)

Step 5 – add the RFM12B radio module. Note that it’s slightly too close to the ISP/SPI connector:

Finished PCBs with RFM12B

But that’s hardly noticeable in the end (also added the 85 mm wire antenna):

It’s called a JeeNode

It works! (using RF12demo).

Here is one more view from the bottom side:

Finished PCBs with RFM12B

The remaining pads are four “ports” (to be used for sensors and all sorts of goodies), and a 4-pin power/I2C bus which can be used to tie multiple units together – or simply to supply power instead of the FTDI connection.

All four “port” pinouts are identical (top/outside view, left-to-right):

  1. IRQ – a pin shared with all ports and tied to INT1
  2. DIO – digital input/output
  3. GND – ground
  4. AIO – analog in, or digital input/output
  5. VCC – 3.3V regulated, ≈ 50 mA max per port
  6. PWR – ≥ 4V, as supplied to the on-board regulator

In some cases, you’ll only need the center pins 3 & 4. In most cases the middle 4 pins are probably sufficient to hook up all sorts of physical devices. And for advanced port use, all 6 pins are available.

The 4-pin power/I2C connector has the following pinout:

  1. PWR – ≥ 4V, as supplied to the on-board regulator
  2. GND – ground
  3. SCL – I2C clock
  4. SDA – I2C data

(as seen from the top FTDI connector side, left-to-right)

The ISP/SPI connector is a hybrid 2×4-pin connector, with a standard 2×3-pin ISP layout for programming on pins 3..8, plus the ATmega168’s PB0 & PB1 lines on pins 1 & 2, respectively (Arduino pins 8 & 9).

Note that this board requires a ≥ 4V external power supply, and runs internally on 3.3V. The FTDI connector is very convenient as it can supply 5V (make sure it’s set to work with 3.3V signals), I used a “USB BUB” from Modern Device (with the jumper set to 3.3V). Small quirk: the FTDI board has to be inserted upside down.

Oh well. My first Arduino-compatible setup with on-board 868 MHz wireless, and IT WORKS!!!

EAGLE schematic (PDF) & board files (jee-pcb-002).

Update – The listing of the “port” pins was reversed: pin 1 is IRQ.

Update #2 – There’s now some basic documentation at JeeNode-v1 as PDF.

The same 10 µF

In Hardware on Feb 11, 2009 at 00:04

Three capacitors, all 10 µF / 16V:

DSC_0063.jpg

That left one looks big. But it isn’t really:

DSC_0064.jpg

It’s unfortunate that they all have different pin spacings (2.5, 1.5, and 1.0 mm, respectively). That means I can’t design for all of them. The large one is not a good option because it sticks out too much when placed upright, so I guess I’ll design for the middle one and hope the tiny one still fits in reasonably well.

(Side note: I really need to get my photo lighting setup sorted out…)

,

RFM12B library for Arduino

In AVR, Software on Feb 10, 2009 at 00:03

Here’s a driver for the RFM12B radio with Arduino’s and similar AVR boards. The radio is connected as follows:

RFM12B

The code is available as RF12.zip or via subversion. It’s packaged as an Arduino library. To try out the included example, you’ll obviously need two Arduino’s + radio modules, connected as above. Then:

  • unpack the above zip as new directory in your Arduino IDE’s “libraries/” folder
  • build and upload the included example sketch to both systems
  • check proper operation by opening the serial port at 57600 baud
  • you should see a “[RF12DEMO]” greeting on both
  • on one unit, type “0i 0i 1i” to set its node ID to 1
  • on the other, type “0i 0i 2i” to set its node ID to 2
  • send a test packet of 7x <N> bytes by typing “<N>s” (<N> = 0..9)
  • you should see the test packet on the other node
  • use “<N>a” to send a test packet and request an ack

The node ID is stored in EEPROM (the demo uses byte 0), so you only need to initialize ID’s once in each node.

This code uses interrupts to do most of the work in the background for transmission as well as reception. The packet buffer is limited to 66 bytes of data. All packets are verified with a 16-bit CRC.

Packets can be sent to a specific node (ID 1..30) or broadcast to all (ID 0). The demo code sends its test packets as broadcasts, but replies with acknowledgements to just the originator. Note that requesting an acknowledgement for broadcast packets only makes sense with two nodes.

Update – instructions for the demo are now slightly different (see the README).


Ignoring imprecise data

In Software on Feb 9, 2009 at 12:05

For some time, I’ve had a second set of calculations running which produces much more accurate and regular data than some of what’s on these past charts:

Picture 1.png

The difference with the graphs is that only readings which come in exactly at the time the counter changes are considered here. All retransmission (i.e. readings tagged with a late time stamp) are simply ignored. Only one retransmission happens to be in this example (the one marked “6+2”), but it still produces consistent results.

It looks like the gas measurements could be improved by tagging all readings in the sensor node instead of at the receiving end of the packets. That way retransmissions would still be tagged properly, even when readings arrive a bit late.

Hmm, this requires running a clock with milli-second accuracy on the sensor board for best results… not entirely trivial over extended periods of time. The sensor board will need to be synchronized to some other clock – either an on-board DCF77 radio or some data received from another node. And I’ll need to use a crystal instead of a resonator (0.005% vs 0.5% drift).


Still not right

In Software on Feb 8, 2009 at 23:55

The gas measurements are still giving me trouble:

Picture 3.png

I’ve changed scales and plotted all values to better see what’s going on over a small time frame. The electricity consumption looks ok now (these are night-time values). But the gas measurements keep jumping up and down by a factor of around 5 all the time!

Maybe there’s a problem with the sensor readout – there are about 4 readings coming in per minute. Or perhaps the automatic idle transmission of packets every 10 seconds is interfering with this cycle?

I don’t know what’s going on… needs more work!


Measurement anomalies

In Software on Feb 7, 2009 at 02:38

Here’s a more detailed view of the measurement quirks related to gas consumption:

Picture 1.png

The yellowish line is electricity usage, which hovers around 200 watt, while the blue line is the calculated gas consumption. What happens is that the heater cycles on and off approximately once every 15 minutes. When off, no gas is consumed so the meter just stops providing pulses. Then, after roughly 10 minutes it starts again at our heater’s standard rate of around 1.5 m3/hr. If you look very closely, you can see that the “zero” values are actually just above zero. That’s because whatever gas flowed until the rotation stops and whatever gas flows right after it starts all gets averaged-out over the entire period.

What needs to be done, I think, is to re-interpret the long averaged-out period as a period of continued flow at the original full rate, followed by zero flow:

Picture 3.png

I.e. the incoming data was treated as the single-hatched “B”, whereas it should be treated as the cross-hatched bar “A”. Both areas are the same.

Actually, this is not 100% accurate since we don’t know whether the meter stopped near the beginning or near the end of its revolution. But there is simply not enough information in the gas measurement data to disambiguate these cases.

However… as you can see, the electricity consumption also has some surprisingly regular small changes. Those measurements suffer from the same problem, but they have a much smaller impact due the the higher measurement rate. My hunch is that these small wattage changes are actually the electricity consumption of the heater, as it turns on and off!

But hey, who cares for now – these are just instant-by-instant consumption rates. The integral of these rates is the total consumption, and those are by definition “accurate” since I’m measuring the very same metering revolutions which the electricity and gas company use to charge me later on.

Update – Here are the results with the above adjustments:

Picture 1.png

Blog redirect

In News on Feb 6, 2009 at 00:05

I’ve “moved” this blog to http://jeelab.equi4.com/ – but it’s all smoke and mirrors really: underneath, it still redirects to the http://jeelab.wordpress.com/ site which continues to host these pages just as before.

Update – I’ve also changed the blog title to match the domain name. Less confusion. See the about page for further details.


Energy plots

In Software on Feb 6, 2009 at 00:03

And here’s the electricity and gas consumption for (part of) last Wednesday:

Picture 1.png

There are some quirks due to the way things are measured. The meter cannot accurately detect when gas consumption drops to zero, since that simply produces no readings. This can be resolved by adding fake readings when a very low consumption is reported, estimating the times when the gas flow stopped and then started again.

The electricity peaks at 19:45 are from the induction stove, the one around 20:15 is probably the close-in boiler.

This Tcl code generates the necessary HTML/JavaScript snippet to produce the plot:

Picture 3.png

All measurement data selection is handled by the “dataset loop” command, which takes a measurement parameter name, the selection range, and the names of the time and value variables to set during the loop.


Temperature graphs

In Software on Feb 5, 2009 at 13:30

Some weather & energy data has been coming in over here for over a month now, logged to text files, and patiently awaiting further processing. Here are the results of a few days of hacking around on the software side of things:

Picture 1.png

This is a test page served by a custom web server, with all data now stored in a database. I’ve used several bits of software which are dear and near to me:

  • the database used is my own trusty Metakit
  • the custom software is written in Tcl
  • the web server is based on my Rig modules
  • the plots are generated in the browser by Flot
  • it’s all in two files using using Tclkit / Starkits

The code is portable and works on Mac OS X, Windows, and Linux. The system requirements are minimal, so it runs just fine on my NSLU2 and Bubba NAS boxes.

Things are starting to come together nicely…


PCB preview

In Uncategorized on Feb 4, 2009 at 13:40

Whee, here’s a picture of my PCB:

pcb-preview.jpg

Still in manufacturing, but it’s becoming very real now!

Update, Feb 6 – the solder mask has been applied:

BIE498992066efec_04_klein.jpg