SwarmB3 pcb

SwarmB3

Working on Swarm Board version 3... so I decided the tinkering hadn't finished yet :)

Currently work in progress.

• PCB in testing, version 4.
• Initial code drafted but a mess.

Development Notes

14/04/26: Lots and lots of debugging between hardware and software. The pcb design worked on the assumption that the UART tx could be inverted in software, as stated in the SAMD51 datasheet. However, it doesn't work as I expected. It seems to invert the data, but the idle state remains high. This causes issues for IR communication because I don't want to saturate the environment with the carrier wave whilst communication is not occuring (idle high, AND'd with clock -> constant carrier wave transmission). I tried a software fix, pulling the gpio low between transmissions. However, I can't seem to restore the GPIO properly without messing up the protocol overall. I got as far as seeing the bit pattern shifted by 1 bit, which is occuring because the receiver is mis-registering the start bit. I tried leaving the GPIO alone, and only enabling/disabling the carrier wave, but the same problem is occuring. When I look at both sides of the communication on the oscilloscope, I can see that for a batch send (like 10 bytes), the first byte is dropping the start bit. I haven't been able to get to the bottom of why. If I do not invert the tx, the problem goes away, but I don't want a non-inverted signal (saturation problem). It could be that the essential problem is that inverting the Tx in SAMD51 doesn't invert the start and stop bits - the datasheet is unclear. It simply says "start and stop unchanged", and I'm not sure if that means overall functionality or logic polarity. It seems like the latter. I tried some other logic gates. Surprisingly, 74hc32 (OR) works as a drop in - however, it does mean that for data logic 1, the data stream is always on, and for data logic 0 actually an on/off pulse train - which is not ideal. The receiver seems quite robust to this, the datasheet has measures for this sort of thing. However, I don't want a board that could cause communication defects alongside from what I am investigating in research. A possible fix is to implement active low LED drivers, which would necessitate an extra transister per UART (e.g. +4). I don't fancy soldering that, so instead I've updated the pcb to pass tx outputs through a 74hc14 first. I've tested this on breadboard and it works fine. It means I can just use the UART interfaces normally without any software SAMD51 inversion. The current code (ItsyBitsy_test) is a mess from all my debugging chopping and changes. I'll refactor after testing the new pcb when it arrives.

10/04/26: The TSDP34156 is active low output when receiving an IR burst. I had thought I would use the M4 SERCOM interface to invert the UART signal logic. It seems like only the start,stop and data are inverted, but the idle signal remains high in either case. I spent some time trying to find a software solution to pull the tx line low, with no luck. Even with no idle, or long bursts of transmission, I was getting gibberish on the receiving end regardless of whether I was inverting Tx or not. With the assumption of inverting in software, the first pcb design had a 74hc08 AND gate to combine the 58khz clock and data. Abandoning this, I first tried a NAND, but that actually just negates the effect of the clock - since a changing clock qualifies as not-and against data or no data. Instead, an OR gate works. With Tx not inverted, if I draw out the truth table, then it means that for a data logic 0 a 58khz burst is created, and for data logic 1 a constant IR signal is made (not modulated, just on).

08/04/26: Some pretty annoying problems with the first PCB prototype! The 74hc08 ground was isolated. The pots for current limiting were not in logical physical locations, not next to their LEDs. I labelled the ItsyBitsy pin 7 wrong, so it wasn't conencted to the 74hc08. Fixed all of that. I've installed two different types of IR LEDs to compare the difference. One is the Vishay TSAL4400 (https://www.vishay.com/en/product/81006/), and the other is an Onsemi QEE113 (https://www.onsemi.com/products/interfaces/infrared/emitting-diodes/qee113). Both have similar characteristics, slightly different radiance patterns. I prefer the form factor of the Onsemi device.

27/03/26: Using the Adafruit SAMD51 board config, they have a wrapped class named sercom around the original defintions SERCOM (difference being lower and upper case). I wanted to invert Tx (maybe Rx) and the Adafruit wrapper hasn't got this implemented yet. These are useful links for low level structures and definitions for SERCOM (SAMD51 in general).

• https://github.com/ace22293/SAMD51/tree/master

• https://github.com/arduino/ArduinoCore-samd/tree/master/cores/arduino

• https://github.com/arduino/ArduinoModule-CMSIS-Atmel/tree/master/CMSIS-Atmel/CMSIS/Device/ATMEL/samd51/include/instance

• https://github.com/arduino/ArduinoModule-CMSIS-Atmel/tree/master/CMSIS-Atmel/CMSIS/Device/ATMEL/samd51/include

• 25/03/26: Started the design of version 3 of the swarm board. The plan is to use the Adafruit ItsyBitsy M4, providing a hardware UART interface for each IR reciever on the pcb. When drafting this PCB, I couldn't find a convenient symbol or footprint, so I've used two rows of pin headers and labels. I also noticed that the symbol for the double row header for the M5Stack Core2 doesn't correspond with the physical footprint - but the enumeration is correct (just a bit confusing).