The r3 boards arrived and… of course there are issues!
I had reversed the supply pins to the TJA1051T/3/1J CAN transceiver. (In my defence, Kicad schematic symbol showed VCC on the bottom and GND on the top but that may be due to the rotation of the symbol!) Solution is to lift the two pins of the SMD chip and connect each with jumper wires to their correct supply signals. The CAN bus connector is close so I tap onto the pins of that. I found it easier to lift the whole chip from the board with a reflow tool, bend the pins then resolder than it is to lift the pins individually.
The TJA1051 comes in various designs with the suffix defining the type. The T/3/1J I have used has a pin (5) that is used to define the controller signal levels. In this case it needs 3.3V to interface with the STM32. I had designed for the TJA1051T which does not use this pin and expects 5V controller. (I could have used 5V as the STM32 has 5V tolerant pins for CAN.) So this pin is floating. Solution is to add a jumper between this pin and 3.3V. There is a potentiomer pin close by which I used for this.
I had reversed the CAN-L & CAN-R indications between the TJA1051 and the bus connector. This results in the bus wires being reversed and the silkscreen legends being reversed. This is not a substantial issue. Solution is to adopt the new bus cabling schedule and ignore (or over-write) the silkscreen labels.
The potentiometer anchor tags are tight in the PCB slots. These slots on the r1 board were far too small and required redrilling. I had increased them but it remains a challenge to insert the pots. They fit (snugly) but it adds to the fabrication effort. (This is a part of the fabrication done here rather than at the factory to allow each board to be customised for its purpose.) Solution is to be more careful and forceful in building these boards but increase the slot length by 0.2mm for next batch.
There are two sets of 4 pin connectors (0.1" pitch) close to each other. One exposes the I2C bus (which is not used but may be useful in the future, e.g. for interfacing with different devices). The other exposes the STM32 programming and debug port. I do not populate these pads with connectors. I temporarily insert jumper wires on dupont connectors to program / debug. This is awkward because the dupont don’t always go in neatly, are prone to falling out, are male pins carrying supply voltage that are prone to shorting on any exposed metal (like tools on the workbench) and the two interface’s silkscreen legends are small so the ports are difficult to distinguish. Solution - I am not sure. I don’t want to add another connector here. it may be okay for prototyping but it would be extra expense and a space intrusion (near edge of board / mounting point) that is undesirable on production boards. If the two ports were closer together they could form a single DIL connection that could be populated with a male header allowing connection of a 8-pole IDC. It would only really be useful for programming (which all boards need once in the lifetime so does not really support this), debugging (which only one board really needs) and exposure of I2C (which probably wants its own port anyway). I did not find this to be an issue with r1 boards that did not have the I2C interface and with which I used a different programming / debugging cable so maybe the solutions could include more prominent silkscreen legends, different shape I2C interface (that could be a 2x2 DIL) and resuse of the previous programming cable. I may rework the PCB to provide these options, keeping the 1x4 SIL for programming.
R3 boards different WS2812 LEDs that are much smaller. I was concerned that this may cause issues. Changing the LED might change its behaviour. This did not happend. Smaller may mean poorer light dispersion. I am yet to check how well they work within mechanical lightboxes but they look fairly bright - probably not as bright as the r1 boards with smaller (more pinpoint like) light output area.
Having implemented these fixes on the r3 boards I now have them working. Yay! I have folded the solutions (except the last one about programming port) back into the PCB design ready for r4 boards.
The LED control works well. Sending the CAN message to set a board’s LED to a mode results in that LED doing what it is told (flash, pulse, on, off, colour, etc.)
Reading switches works well. Debounce is good with no false or missing triggers. The board decodes the push type and sends an appropriate CAN message, e.g. press, short release, long (bold) release, longer press and hold.
Reading potentiometers works well. All the pots on the first r3 test board read 0 to 1019. That is 5 units lower than full scale but consistent across all pots so probably relates to the reference voltage. (I should investigate further to ensure this does not drift.) I need to test other boards to see if there is a need for calibration. The tracking is accurate with messages being sent for change of value. The filtering works well. The hardware RC filter and software exponetial moving average (EMA) filter are effective. There is no discernable noise (repeating sending adjacent values when idle) whilst still being responsive to small / slow changes. The filtering thins the data throughput for large / fast changes but still sends significant quantity of data points. It looks like the filter is tuned quite well with an EMA factor of 0.2. I need to test how this scales with multiple modules attached. (We generally have two or fewer hands so there shouldn’t be too many simultaneous knobs being twiddled!) For those of you designing knobs driven interfaces I recommend using an EMA filter. It is trivial to implement and provides very effective and tunable filtering of ADC signals.
The CAN bus seems effective. This is carried on a 1m ribbon cable with 10 x 6-pole IDC connectors. The Brain is connected to one end with onboard bus termination and a simple resistor terminator attaches to the other end. The remaining 8 connectors, spaced at 0.1m intervals connect to panels which seems to work well for 10HP panels in a 104HP enclosure. (The Brain takes 24HP.) (The mathematically astute may notice the fence post error here. The cable is in fact 0.9m long.) Wiring is:
- +5V
- +5V
- CAN-L
- CAN-H
- GND
- GND
The CAN protocol is only partially implemented in the STM32F103 firmware. (I am porting over the previous firmware to the CAN based r3 boards.)
Panel detection works. It takes approx. 2s to detect the panel during which the panel pulses its LEDs blue. (I will review the animation type and colour after building a few fully complete panels.) I am yet to test how this scales. This detection occurs at startup and when a panel is added to an already running system.
Setting LED and monitoring sensors (pots & switches) seems okay as desribed above. Each panel sends a CAN message when it detects a change of sensor value. I need to test how this scales with multiple panels and how effective the collision detection and recover is. I also need to test how various failure modes manifest, e.g. a panel becoming noisy.
I have not yet implemented firmware updates over CAN. (Some versions of STM32 support this natively, including the STMF072 used in the r1 boards but this requires a direct one-to-one connection so not beneficial in this scenario.) This ideally needs to be done before production but is currently a fairly low priority task.
I also received new front panels. These are similar to the ones used in the r1 prototype, made with PCB fabrication. The new front panels are black (r1 were purple) with white silkscreen. The switch and pot centres were standardised on the r3 PCBs so the new panels fit better and are reversible. The vertical offset of the PCB from front panel is also adjusted to better fit Eurorack enclosures. I have a VCO design on one side and ADSR on the other. (I paid the extra to remove the fabrication number from the surface.) White on black looks quite nice. They may have a slightly higher sheen (gloss) than would be ideal (similar to the the previous purple panels) but may be okay. Some of the text may be more difficult to read. This may be a change of font size / typeface and / or the difference in contrast. I need to do some testing in different lighting conditions at different angles and distances with users with varying eyesight. (Luckily I have some young and older adults here that can help with that.) Some of the text was squeezed / stretched to fit its space and this has not worked well, e.g. ADSR looks a bit odd. (But style is subjective and I will garner opinion before making changes.) These front panels have all the holes drilled for all possible sensors (switches and pots that do use the same size hole with same centres). This allows free testing of any combination of pots / switches but exposes holes that are not required for some panels, e.g. the VCO and ADSR have unused holes in different locations. For testing I can ignore this or insert a bung. For production I need to decide whether such a bung would be acceptable (I currently doubt that) or whether each panel should have the right quantity of holes (like the r1 front panels). The more panels that can be paired with another, mirrored drill pattern, the more double sided boards can be designed, reducing the quantity of stock required which in turn reduces turn-around times.
I also want to test other coloured boards and possibly matt finishes (not available from my current fabrication plant). I am still trying to decide whether to have a single colour panel for all riban modular panels or to have different colours for different types / catagories of panel. I like both options but worry that the multicoloured option may be limited by quantity of colours available and also, if the PCB fabrication method proves inadequate, different colours may prove more challenging at fabrication stage.
I am currently using JLCPCB in China to fabricate PCB and front panels. They are very good and I am yet to have any significant issues with their service. The front panels can have blemishes which may result in me chosing a different fabrication method (or embracing the flaws / encorporating into the design!!!). Their costs are reasonable and scale with quantity but delivery costs seem to scale inversely which results in the base fabrication costs exceeding business limits. Their lead time is also fairly good but combined with affordable delivery I am not sure I can use them for JIT fabrication for customer orders, i.e. avoiding carrying large quantities of stock locally. The more generic fabrication I can design, the better. These 10HP boards work well for that but the front panels, less so.
So, in summary - the r3 boards seem to work well. There are some design errors that need resolving and further testing to be done before r4 are ordered. The move to the different microcontroller, LED and CAN has been successful. The physical layout has been improved and lessons (to be) learned about astetics.