Now, at the end of the year, looking back, how did the Aronia turn out? What worked, what didn’t, what did I learn and what would I do next time?
What Did Work
The TS7500 worked quite well, very easy to program (it’s basically straight C/C++ for linux), enough example code to get you into trouble and back out of it and the tech support people are very friendly, fast and helpful.
In the past, I had tried running a RS232 through the XUARTS at very high speeds (921600 baud) for continuous streaming (not burst transfers) and it had ended up giving me grief. The TS7500 locks the SPI bus every second for something, and that was enough for me to lose packets of data. But now, I decided to go through the USB port, through an FTDI USB serial port chip (more on this in another post), and not a single lost packet in 6 months of operation. I you don’t even have to boot all the way into linux – the image on the sdcard loads USB drive drivers, checks for a script called “tsinit” on the USB drive (if present) and executes it. I put all my code in that tsinit script (loading USB serial / ftdi drivers, making folders, setting up UARTS) and walked away!
The serial-enabled LCD from Seeedstudios was dead easy to use, you just have to make sure to flush commands before issuing more, since the UART driver on linux is buffered, and if you try to do packet-wait-packet type transfers, it won’t work as expected.
The Aronia PCB itself was designed with enough flexibility to change the way it was put together quite easily. I was using Molex Picoblades for my main connectors, but had also put in through-holes just in case. In the end, I ended up replacing some Picoblade connectors for direct soldering – much faster and easier, and I didn’t not require that particular part to be removable.
What Did Not Work
Well… the TS7500 also gave me its fair share of grief. Well, it’s mainly that I was trying to use the TS7500 as a pure embedded, real-time platform, which its not, so it’s my fault really. I was reading data off 3 serial ports, at different baud rates, with varying amount of data coming through. In theory, I should be getting packets like this: A, A, A, B, B, C, A, A, A, B, C, A, A, A, B, B, C, … (imagine I send 3x A packets, then 2x B packets, 1x C packet, etc…), but in reality, since the linux USB drivers would be “helping me” by buffering, I would read 20x A packets, then 10x C, then 5x B… etc, so not really as interleaved at I had hoped. In the end, it didn’t matter as much, since the A packet is the “master” one, and the others don’t really change that much. In hindsight, I need a proper embedded system, with proper low-latency interrupts and where I have control at the end of each byte read.
We also blew up about 4 of these TS7500 boxes, kinda. We don’t actually know what’s going on with them. But they boot, get to the prompt screen, then reboot. Forever… We are abusing them quite a bit, so it’s quite a surprise that they are surviving this well though.
I had a couple of design flaws in the Aronia PCB. First and most important: I knew nothing about thermal design (operative word: knew, past tense). I now know a lot more! We were plugging these guys into 14v, I was then regulating to 5V with about 0.7A current usage. On a linear regulator – that’s a LOT of wattage coming off it. with only 2.5cm^2 of radiating copper thermal pad, in an airtight polycarbonate box. Yes, these linear regulators got so incredibly hot that they actually discoloured the PCB! I tried adding a 2x10cm aluminium plate, but that was also getting into the 90ºC+ range after 5 minutes. I ended up getting some SMPS from Recom, some 1A 34v-in, 5v-out ones and reworking them onto the board.
I also added, on the wires supplying the current, some diodes and fused to make sure that nothing blows up (except the fuse). All this should have been on the board, not added as an afterthought…
Another thing I would change with the PCB is to put the connectors at the very edge of the board instead of the middle. In its current form, I have to remove the TS7500 from on top so I can plug a connector in, which is very annoying when in the field. And of course, adding a console header to the board helps!
A massive let-down for me was my “brilliant” “UPS” “solution” that I had “envisioned”! Here’s my theory: 12V -> 5V regulator -> LiPo Rider Pro -> Aronia. The LiPo Rider Pro takes 5V in and outputs 5V. It also has a connector for a single-cell LiPo battery. When running off its input, it will charge the LiPo, when the input is disconnected, it will seamlessly switch to LiPo and boost it to 5V – exactly as what I want! The only problem is that the LiPo Rider does not care about the minimum voltage of the cell, so it will squeeze it for all the juice it has, even if it means over-discharging the cell. The cell has a built-in over-discharge protection circuit, where it stops giving anything if the voltage falls below 3.4V (or 3.3V, I forget). This, for the moment, sounds good. Except that the LiPo Rider will not supply anything on its output if a battery is not connected, even if it has a perfectly good 5V input. And this condition is exactly what happens when the battery is over-discharged, that it looks like no battery is there!
In the end, I just got rid of that whole thing and if power goes down, then power goes down. In practice, it didn’t really affect us much, but it did leaving me scratching my head for a few afternoons.