PCB designs, Ethernet, and PoE

First off, I am working on adding Ethernet to my ESP32S3 designs. I am going for an KSZ8851SNL SPI Ethernet MAC+PHY, mainly because the ESP IDF has a module for this - so it should be a couple of lines of code (LOL).

I am also going for a Silvertel PoE module.

At this stage I have designed, and ordered, a board to allow me to prove the concept. It is somewhat more expensive than I hoped as I am using a large mag-jack, but I should be able to improved that. At this stage I want to prove it works, both Ethernet and PoE. I should have boards late next week.

But this has led me to thinking of a couple of changes to designs of some of my boards.

Faikout Remote

The Faikout is a small board you fit in a Daikin aircon. It works with Home Assistant, and that is how most people use it, but it also has a simple web control page via WiFi.

The Faikout Remote is designed for situations where this hi tech approach is not ideal, e.g. my guest room, and people without HA. It has a display and joystick button to show temperature, settings and allow control of the aircon via the Faikout. It actually connects to the Faikout over BLE, so can be used when no HA, or even without any WiFi.

Is is USB-C powered so easy to put on a wall with a simple USB lead. It has a temperature sensor, so can work as the temperature reference for Faikout auto mode, but can also work with small battery powered BLE temperature sensors if you want the reference elsewhere, e.g. by a bed.

The problem is I have gone overkill on this. The design also has a load of environmental monitoring sensors, including an expensive CO₂ sensor. This makes it unnecessarily expensive. So I plan to simplify things.

New Faikout Remote

The new Faikout Remote will have the display and joystick (though a more robust joystick), and temperature sensor (but also works with BLE sensors), and an IR receiver, but that is all.

The idea is it is cheaper and just works as a Faikout Remote. The IR is because you can use it with a Daikin IR remote (cover the actual IR receiver in the Daikin aircon).

This is now sold on shop.revk.uk with resin case and display. 

Env monitor board

Having removed all the environmental stuff from the Faikout Remote I would make a new Environment board. It would handle a display, but obviously this is optional as many cases do not need a display. It would include the sensors that were in the Faikout Remote...

• CO₂
• Humidity
• Temperature
• Pressure
• Noise
• Light (including colour)

The temperature uses a built in SHT40 temperature sensor (on thin long track with no ground plane, for some thermal isolation), temperature from SCD41, and from GZP6816D, but also WAGO for DS18B20, and, of course BLE sensors. The DS18B20 are commonly available as a probe on a lead, and one or more can be connected. This is ideal for things like data centre use, for front and back of rack, or home usage for inside and outside temperatures.

I have also made it so the display can be fitted to board, or use the supplied lead and plugged in to board.

It would not have the joystick nor IR receiver.

Connectivity and power

This is where it gets more fun - the plan is Ethernet, so it can work on WiFi or Ethernet, and PoE so it can work on PoE or USB-C or DC 5V-28V. The PoE would be a module (solder in), so optional.

• Home use would typically be USB-C and WiFi
• Office use (and well cabled home use) would typically be PoE
• Data centre use would typically be Ethernet and USB-C, as data centres usually do not have WiFi nor PoE.

This should make it a very flexible environmental monitor, which is increasingly important for things like workplace monitoring for health and safety, as well as home monitoring.

This would be sold on shop.revk.uk with options for PoE, Display, and DS18B20 sensors.

I expect to get started on these soon, but obviously I really need to wait for my proof of concept first - that does not usually stop me :-)

Latest render...

USB project

I am making a simple USB device. It looks like this. OK this is 3rd version, after some wiring issues.

What does it do?

Well, it is simple, it is a smart card reader, but also works as a passive smart card in-line monitor. The "card" on the side can be snapped off to just be a reader.

This means I can talk to, for example, SIM cards. We sell SIM cards, and this can allow us to read the ICCID, but some cards we have been able to use ADM1 codes to change operator name and other such things.

We used to do this in the card printer which has a contact station. But the latest batches of SIMs do not work in the printer properly, which is a shame, so working on staff having a reader. I hope we can get nicer cards in future as they are nice when custom printed.

But I can buy a smart card reader? Well yes, but making one is (a) fun and educational, and (b) allows us to make a reader that simply works as a USB keyboard typing the ICCID. Normal card readers won't do that, and you need drivers and code. This will be a neat accessory for staff handling SIM cards.

But I may as well also make it in to a CCID compliant smart card USB reader device whilst I am at it. Why not?

Why a monitor as well

This is simple really - making it a monitor is kind of temporary, hence snap off design. It allows me to see in practice the exact working of card readers. There is a spec, well several versions of specs. Last time I looked at this is was all simple 9600 Baud data each way. Now it is initially roughly 9600 Baud but actually 1/372 of the clock, and then it changes clock divide and Baud rate with a message (which I have yet to find documented). This kind of shows why the monitor was useful, if I cannot find the spec that defines this!

Even just the T=0 protocol is fun. That is well defined, and ETSI document it for free (yay!). But a passive monitor has fun splitting things up cleanly as it does not know which way data is being sent. I also ended up basically clocking in bit streams using ESP32 RMT hardware and then auto Baud rate on that. To my surprise it does work, and I can monitor the card exchanges with a real reader even with the Baud rate changes.

It is a shame the ESP32 UART cannot used an external clock with defined divide rate, but I could not find a way to do that, hence not using UART but using RMT and working out Baud rate from that. RMT basically allows you to DMA clock-in high resolution timings of 0 and 1 on the input, so software UART from there from those timings.

USB host side

This turns out to be simple. I used libusb on macOS (homebrew), and have used it with a printer before on linux. It allows me to find and connect to the device and simply do bulk data out and in messages.

The CCID standard made it easy to talk to the reader, power on the card, and send and receive messages. Very simple to get the ICCID.

This gives me a good test platform for making the CCID USB device side.

Card interface

The card interface as a reader is way simpler than monitoring as I control the clock and dictate the Baud rate. I used the ESP32 PWM to generate the clock (not sure if a better way, but did not find one). I used the UART to talk to the card.

It is not perfect - a card can expect defined extra guard time which is more than usual 2 stop bits, but the cards I am playing with seem happy. Also T=0 has a pull low during guard time if parity error mode, which I have no way we handle. The good news is that the direct connection to a card leaves very little room for bit errors. That said I had to change the recommended 20k pull up to 10k when working at 250,000 Baud.

The T=0 protocol is not that hard to then do, and I am talking to my SIM cards reliably.

Yes, T=1 and others maybe one day, but not for now. All of the cards I am working with use T=0.

USB client side

I don't expect to support all of CCID initially, but should be able to do the basics. I actually want two modes here, a keyboard to type an ICCID, and a CCID USB reader.

TinyUSB is a fucking nightmare, sorry to say, and apologies to those working on it. I am sure there are reasons, but it has been very very hard work just getting started.

My biggest issue is the load of different versions and documentation. Even the very latest ESP IDF documents on tinyusb (saying add dependency esp_tinyusb not tinyusb) have the basic initial examples that simple do not match the library!

There are examples for a USB HID device, but they are confusing to me (yes!), and the code seems to cover HID, CDC, MSD, and so on - some specific device classes. I eventually found some mention of Vendor specific class which may do what I want.

So yes, finally, the answer is using tinyusb and not esp_tinyusb. And I can make that work, sort of. I think a separate blog post with code examples once done.

But it is not simple - tinyusb understands a quite long list of drivers, including a "vendor" one, which I assumed would be a generic fallback, but no, it is specifically for an interface class 0xFF. I can't find a fallback/generic one yet. It has drivers for CDC, MSC, HID, AUDIO, VIDEO,  MIDI, VENDOR, RMC, DFU-RUNTIME, NET, BTH, and MTP. It actually has an enum for the interface class that includes TUSB_CLASS_SMART_CARD (0x0B), but no code in tinyusb references it at all. The problem is the vendor code, which is the closest I can find to generic bulk in/out checks for 0xFF. I have deleted the check to make some progress for now. Would be nice to find a legit way to do that though.

Arg! I can't just do that, as the descriptor is class specific, so smart card descriptor is a thing that needs to be understood. It seems I can receive packets, but not send them!

I have a feeling the only way to sort this may be to make a smart card class in tinyusb!

Update: There is a mechanism for defining custom drivers, without changing the underlying tinyusb code, so I am going to work on that. Thanks to the team at tinyusb for help. Published details on separate blog.

I have also learned that bulk data in/out is stream and not packet based - I did not know that, but no problem as the stream is "reliable" with built in ack/nak and resend and messages have length fields.

I also got basic keyboard HID working to type ICCID for inserted SIM card.

Publishing

The code is likely to be very narrow to our needs, and so this is actually one of the few projects not published open source, yet, but I may sell the hardware at some point as I'll have a few spares. I may do some open source stuff for it eventually.

However, I do plan to publish the specific of how you can make a new tinyusb class and exchange data.

Update: All working! Taken me a couple of weeks, but working. Yay!

My ultimate e-paper board...

I have stock of some very nice Waveshare 7.5" E-paper panels with bonded glass and black border. They are very cool. I made a driver board to fit on the back, and it works well. It is on Tindie.

I then made a new board with NFC reader through the glass which is very cool. I use for access control on the front door. But I think it can work as a card and so work as a WiFi NDEF NFC even - need to work on code for that.

But I am working on the next version, and am interested in comments.

One of the main uses of these is household displays for things, including environmental monitoring. So the NFC based panel controller board has...

• ESP32-S3-MINI-1-N4-R2 (Dual CPU, 4M flash, 2M SPI RAM).
• E-paper panel controller and power, obviously.
• Micro SD card slot.
  
• Power from USB-C (two positions) or WAGO DC 5V-17V.
• Designed to work with button-fix clip on the back to mount easily on a wall.
• 24 WS2812 RGB LEDs around the edge, plus one for status by SD slot, and one general status.
• 2 pin WAGO contact input (e.g. for doorbell push).
• PN532 NFC compatible with DESFire, and can work as a card to NDEF WiFi details, etc.
• Separate WAGO power and control for PN532, and connected internally to allow local working.

But the new bits are...

• SCD41 CO₂ and humidity (and temperature).
• SHT40 temperature.
• GZP6816D atmospheric pressure.
• T3902 MEMS microphone for sound.
• DS18B20 connection for external temperature sensors (WAGO).
• Updated WS2812 LEDs that don't get easily knocked off the board.
• Switched power control for PN532.
• Switched power control for E-Paper.
• Switched power output 3.3V (WAGO)

This adds some cost, but I think makes for a pretty awesome controller.

What do you think? (Update - I have ordered some)