UltraMod Generation 3
The UltraMod Gen2 hardware worked for nearly 3 years. I didn't intend it to be so long before an update, but a bunch of other stuff got in the way, and the time went by pretty quick.
This project is still under active development. The semi-current status of the project can be found here.
Gen 3 Board Updates
The Gen2 board worked really well, actually. There were only two real issues. Issue number one was that there were times when the data logging to the flash card could not keep up with the ECU data rate. This seemed to be related to the FAT file-system used by the flash cards: at times, the ARM would seem to spend a second or two looking for a spare sector that it could write to.
Issue number 2 was that I really do intend to make a few of these available for other people. I don't care if I cut a few corners for myself, but I figure that if other people are going to spend their own money on these, I should do my best to make it as well as I can. To that end, I made the board bigger strictly so that it would have 4 screw mounting points to the ECU mainboard instead of the two screw mounts I used in Gen 2. That should keep vibration problems at bay. The strange outline is required to clear tall components on the mainboard.
A related issue is that Gen 2 used surface-mount pins to connect to the EPROM socket on the mainboard. In theory, this is great: more room for parts on the topside. In practice, surface mount pins are nowhere near as strong as through-hole pins. If someone were to remove the board from their ECU more than once or twice, the surface-mount pins would shear off the PCB. I know that from experience now!
In the two years since the last design, GPS modules have gotten smaller, faster, and cheaper. I found a Venus 634FLPx GPS engine that tracks 14 channels simultaneously, but more importantly, delivers position updates at 10 Hz (10 times per second). In contrast, the Gen 2 uBlox GPS module would only report at 4 Hz. The price of the old one was around $150, while the new one is only $60.
The other changes were not really required, but they make the end product a little nicer.
The actual change-list for this revision is:
- Mechanical #1: The board uses 4 mounting points on the main ECU motherboard instead of 2.
- Mechanical #2: The board uses through-hole pins to attach the board to the EPROM socket instead of surface-mount pins.
- Storage: The data logging storage medium is Micro-SD now instead of Mini-SD. Reasons: Mini-SD is dead, and Micro-SD takes up less room.
- GPS: I am now using a Venus 634FLPx GPS engine.
- Data Logging: Added circuitry to reduce the CPU load on the ARM while logging.
- USB Port: Retired.
- Bling: Two more LEDs added: Blue and Orange.
There were only three small changes to the wiring that the ARM software needs to know about, so it should only take an hour or so to update the ARM software for the new wiring. The big delay will be updating the ARM software to use the new GPS module. That took a fair bit of time the first time around. Unfortunately, this new module uses a completely different command and data format, so I bet that integrating this new module will take at least a couple of weeks of free time.
Layout
This time, I didn't use the autorouter at all. I actually like routing boards, so it was pretty fun. The result can be seen below (top side). The copper flood is turned off so you can see the wires more easily.
This is the bottom side. The copper flood is 'on' so you can see the quasi ground plane (pretty much all the blue):
The oddball shape is required to pick up two extra mounting screws while avoiding tall components on the mainboard. The teal-green line around the outside is the line that the NC router will use to create the outline of the board.
This version of the board finally uses a soldermask for ease of assembly and extra reliability. The topside of the new board is shown below:
The soldermask is beautiful! I don't know why I never did it before, except that it costs more money. It certainly looks professional...
Assembly
I got a friend from work to solder down the three big surface-mount AISCs to the board: CPU, Flash, and bus buffer. I soldered the rest. It is not hard to tell what he did and what I did: he is a professional, and I am not.
You may notice that I did not mount the new GPS module yet. I was waiting to see if the basic board was going to be a rock, or if it was going to work before soldering down another $60 part.
I was also happy that the mounting screwholes all lined up as expected. I didn't bother with the 4th screw (upper left) due to a combination of laziness and wanting to go for a ride. You can also see why the board contour had to jog this way and that to avoid tall parts on the mainboard.
Board Bringup
It took about 3-4 days to perform the board bringup. It actually went pretty smoothly. Most of the bringup issues were ARM firmware issues, which were relatively easy to fix.
The new blue LED is really bright compared to the rest of them. The new orange LED is almost identical in color to the red LED, which is also pretty orange in color. The green LED is a pukey yellow-green. I want to change them to a redder red and a greener green for the next version.
V3.0 Hardware Bug
Unfortunately, the biggest issue I encountered was a hardware problem: I was not getting any interrupts from the main HC11 CPU to the ARM CPU on my board. It took about 10 seconds of looking at the schematic to realize that I had made a truly bonehead design mistake: I tied three unused NAND gates to GND (not Vcc!) meaning that the output of the NAND gate was always 0. The result would be no interrupts.
However, many things are repairable, and this was no exception. I had to perform some microsurgery under a microscope to unsolder the affected legs of the ASIC, and lift them in the air. Once airborne, I could tie wire to them that would go to the right place. It only took about 15 minutes to fix, which was way shorter than the 1 hour and 45 that it took to drive in to work and back on a Saturday. I had to do it at work so I could do the repair under a nice stereo microscope using a nice fine-point soldering iron.
Here you can see a closeup of the wirewrap wire I had to add in order to tie the lifted legs to a handy via that supplied Vcc to the ASIC. The wire on the top is connecting two adjacent pins, which is why you only see two wires to fix three inputs.
This design problem means that there will definitely be a V3.1 version of the board in the future. That's OK, I have a small list of minor improvements to add to that version.
Current Status
The repaired board is working and installed on the motorbike. I went for an inaugural ride. The results were good, except that the Micro SD card still cannot keep up with the data rate, even though the V3.0 CPU has significantly more CPU cycles available to service it. The issue would seem to be that the ARM is waiting for the SD card more than I thought.
Here is a snippet of that ride. Of special interest is the black line on the graph which indicates the length of the queue (how full it is). Click the pic if you want a bigger view.
You can see that the queue drains very slowly as compared to the rate that it can fill. The slow drain is due to a filesystem 'sync' operation. I measured the sync time and the write time, and it turns out that a write operation is somewhere between two and six times faster than a sync operation.
At this point, I believe that continuously syncing the filesystem is unnecessary. I think that a good compromise is to not sync unless the queue is almost empty. That would allow the queue to drain a few times faster under normal circumstances. It also should mean that the queue would tend to be empty when idling, which is the typical case just before the bike (and therefore the ECU) gets turned off. The point of the sync is to make sure that the filesystem is in some reasonably consistent state when the power goes off, so it seems like a reasonable theory.
I need to go for another ride to prove it though. Sounds like a good excuse anyway...
I made a change so that I would not sync the filesystem unless the queue length was less than 100 items. Today's commute shows that the new Q handling mechanism seems to be a complete success.
The black line is the queue length. I was droning down the freeway in second gear between 7-8000 RPM just to make sure that the queue was getting loaded with lots of events. You can see that the queue length stays less than about 1600 items at its worst. You can also see how quickly it recovers when the load drops. The old mechanism was going unstable at only 4000 RPM, so this represents a great improvement.
It will be worth it in the end.
Wright Cyclone in full song.