PCBs: an increase in coolness

Haha! I followed through on my PCB threat - and now have a bunch of them waiting to be made somewhere in China. Fantastically using them actually brings the cost of the project down as with the introductory discount they came to less than £1 per item (including shipping). Given that this is less than the soldered mess on the strip-board it is a bit of a no-brainer to use the PCBs.

Given I had already put together the schematic to design the strip-board layout it was relatively straightforward to design the PCB. The massive advantage of PCBs is how close different signals can be routed. This and complete routing flexibility on both sides of the (two layer) board mean that the layout uses 25% less area with a large area with only flat components (for the battery to fit onto). Additionally the LEDs and pinouts are all now in far better locations which is a real help.

KiCad Rendering, gets even better when you actually provide
full 3d models for your components!

The Worms - this step was so straightforward, I don't know why I
have not done it before.

The things this design still misses is attachment points (not a problem if you just use hot glue...) and an on board Serial to USB converter. Given how straightforward the design and order process has been I may opt to move to surface mount components rather swiftly. This will reduce the required PCB area drastically (everything will be smaller), leaving space for drill holes and extra hardware, and the cost reduction (everything should be cheaper) will mean I have budget room for extra hardware. I may even have to start considering integrating in the RFID stuff and actually thinking about power consumption.

NOOOOOOOOOOOO - too polished, too complete, I NEED THE HOT GLUE AND 0-OHM SOLDER BLOB RESISTORS. Darn you engineering maturity, you can't get me that easily!!

This is actually quite a nice step for me. Previously I have always relied on Monsieur Miroshnikov to throw the PCBs together and order them (generally while I dove deep, deep into a pile of code), it is going to be a bit of a change to only have myself to blame when the power rails short out!

Next up in the immediate future is to sort out the enclosures for the proof of concept hardware. The new PCB design should permit easier packing into a box (see my comment about batteries). Everything will probably end up being be glued to the lid of a standard enclosure (with flanges for attaching to controls) just because that keep everything accessible. Of course the best bit will be drilling holes into the weatherproof box to let the LEDs peek out!

Pushing Past Power Problems (perhaps)

Making a semi-final product today allowed me to finally start taking semi-final power consumption measurements. These were done by inserting a small resistance into the positive power supply connection and then measuring the voltage over it (my multi-meter was not sensitive enough for direct current measurements).

These were terrifying, unmodified the board pulled almost 60mA  in its idle state, giving it just over a day of life on a single 18650 lithium ion cell. This is clearly far less than I had hoped and indicates that power consumption is now something I should be worried about. Off we go on a hacky adventure!

First off was removing the 5V regulator which (given it had been shorted out anyway) was just wasting power. That saved a full 5mA of consumption.

The next step was to stutter the RF field from the reader, adding periods where it is turned off, for instance when the microcontroller is doing non-RFID things. Additionally the addition of a sleep period to the polling cycle (with the RF field off) massively reduces the RF field duty cycle and in tests did not really change the user experience (and I was looking for it). That saves another 10mA and being more aggressive on the sleep saved a further 10mA. This pushes the time on single cell up to 3 days.

Clearly I have been optimistic that the cells will actually be able to discharge their full rated capacity, so maybe 1.5 days is more like it. This still allows the proof of concept to be programmed the day before any field trials and left on over night without having any danger of it running out of power!

The interesting thing about this development is that it indicates the next big development required of the ODOTS on its path to becoming ready for certification (certification being expensive and something I only really want to do once in the future)(And something that will be necessary to bring the ODOTS, or derived system, to the mass market). Frankly the current hardware architecture is not optimised for power consumption in any way at all, the use of Arduino in particular is a bit of a liability as it does not provide fine control over AtMega peripheral activation. This may be why I eventually shift over to a different architecture in the future. While I have made an effort to tame the ravenous beast that is the RF field the MRFC522 (or one of its alternatives) will provide methods for reducing its appetite further. I have commented in the past about the ability for the ST Micro chips to passively detect tags, this would be ideal as it would massively reduce the power consumption with potentially little (randomised) impact on competitor visit recording times.

I suppose my dreams of networking the ODOTS units with LoRa and implementing a 6WLoPAN network are going to be a long way off indeed!

Small steps are never as easy as you imagine.

The first stripboard prototype has now been put together and it was worth doing. It works, but has taught me a lot about how the proof of concept design is likely to go together.

Prototype, mk 2: "Ever closer to approximate perfection"

The strip board module, with the AtMega chip, clock, leds, buzzer,
voltage regulators and many many pinouts.

First observation from putting it together was that it took most of a day, and was incredibly fiddly. The build time may come down with repetition and the fiddlyness could be remedied with an extra bit of clever design, but for something I want to be straightforward to put together, it is not acceptable. Therefore I may have to make a diversion to PCB land, which will delay the full completion of the proof of concept system (as as adding cost) but will make the design much easier to build.

A good test for new hardware is to use it. Typically this test is used when you have not put in good testing points, test procedures, or you are bored and want excitement. Also typically new hardware will fail this test and you have to spend twice as long fixing it. Test procedures for the strip board layout included (in order, and initially with no power or DIP chips):

1. Testing for Power-Ground shorts (good for not blowing up components when you plug it in).
2. Test for signal-ground shorts (same).
3. Test for Micro-controller to endpoint signal wire/trace continuity.
4. Test to see if the voltage rails had the right voltage (with battery plugged in).

Then the following functionality tests were performed (once the DIP chips had been socketed, and the micro-controller programmed):

1. [PRIOR to all other tests, the AtMega chip was used in the breadboard setup to read cards and demonstrate basic functionality, proving it worked)]
2. Test to see if the clock worked (and the buzzer), performed by waiting a minute to see if the 'I-updated-from-the-RTC' blip activated.
3. Test to see if the serial interface (through the now empty UNO board) still worked.
4. Test to see if the RFID reader worked.

Absurdly the tests were all passed until the last one. The brilliance of not doing the 'plug and go' test was that I knew the RFID reader/wiring to the RFID reader was at fault. Plugging the RFID reader back into the breadboard setup showed it was still working, which meant the problem was in the wiring. Quick testing indicated one of the pins was shorted to ground, which it was due to some splashed solder. Fixing this meant the device worked normally, but such a fault indicates that even when you know the design well, test thoroughly and have plenty of soldering experience with these sorts of components it is still tricky to get a working board. If others are to be able to replicate the design it has to have a fair chance of working first time with no debugging, something this approach is evidently unlikely to achieve.

I lie when I say all tests were passed, the 5V regulator was actually counterproductive with the 5V supply - I had expected it to operate without any voltage drop but it appeared to just not work! Therefore it was just shorted out, and will be in any future designs that use the magic Poundland power supplies.

The placement of components is also an issue. Due to the nature of the Strip board, placement of components (when optimising for reduced soldering) is not exactly free, and as a result (as you may have spotted in the photo of the board), the board is not set out particularly well. The LEDS are recessed, which is not ideal if they are to be visible. The Header pins are spread out all over the board, not ideal for happy wiring in the final enclosure. (Though to be fair I have not thought much about how the final enclosure will look yet). Moving these bits around requires more flexibility in routing than the strip board can give me, which does not bode well for it!

To sum up, stripboard: meh, PCB: possibly worth the extra expense...

Next step will be to think about the enclosure, then go off and order the enclosures, RFID units and PCBs. Then take a trip to documentation land while I wait for them to arrive!

Website fun.

Hmmmmmm...

ODOTS is intended as an accessible project (broken record time WHOOP WHOOP), which means that ideally the general public should be able to snoop around the design documents and software with little effort. I have spent today throwing together a Github Pages website to do exactly this:  https://ljones278.github.io/ODOTS-Release/. 

the website

Eventually it will sit on top of a repository that contains all the latest release versions of software and hardware designs and act as a guide on which files to use for which purpose. It can also be used as an update bulletin, which will be useful for showing off to potential users or just the orienteering community at large.

Eagle eyed readers will notice the new logo, this is actually just a re-work of the old one so that it can be used in-line rather than as a separate image. This is far more handy, I actually made it so that it would fit in my User Guide footers!

In line logo.

The other thing to happen today was that RS managed to turn around the order I put in yesterday in record time and I received all of the parts for the first Proof of Concept test build!

Real orders come in boxes.

 I was not really mentally prepared for the task of soldering up the board for the first time, so I will admit that the website may actually be a massive exercise in procrastination! The other step in delaying the inevitable was to sort all the components into component boxes. This is a pretty cool step as it means that I know when I am starting to run low on any single component, as well as being able to quickly spot which type of resistor is which. I am aware of the ESD risks, hence the AtMega chips are still in their bag, but for the rest of them it does not really pose a risk here.

So organised...

Finally, the last thing done yesterday was to pick up the proof of concept power supplies, which are the power banks isible in the photo above. These are pretty nifty, containing a LiIon cell, a charging point and an inbuilt voltage regulator, and all for a price that I could not buy the battery for. (What do you mean, "cut corners". I am sure the batteries and charges are made to the normal high quality standards of their source shop).((Poundland)).

The home straight (time to solder on...)

The last couple of weeks have been spent positioning the project for its final sprint (before the long, long cool down of debugging and documentation correction). This means that this afternoon I sent off a hefty order to the component people to request most of the bits I will need to put together the Proof of Concept!

The first thing to finish off was the interface software, the bit running on a big computer which will allow people to configure how the ODOTS operates, download competitor card data and so on. This is now all done and partially debugged (more on it in another post).

The second thing was to transpose the hardware design to a strip-board using an atmega328p. This is the bit that gets my inner Electronic Engineer very happy, bugs can be solved with extra wires and spotted with your nose, design turns into connect-the-dots and the seemingly random (but essential) components all work their way out of the woodwork. Another advantage is that I now know how much the proof of concept will cost to make. While component costs come to £20.51 (such precision, so exciting), which is more than my original goal, I am not to worried, I have not made an enormous effort to hunt out cheap components so it is likely in another revision many pounds could come off that total.

The design has been put together in KiCad (k-eye-cad or key-cad depending on which side of the flame-war you sit) a free PCB design tool that can also do strip board designs quite well - just by putting all the back-copper traces horizontal! In the layout below Red is being used for the provided strips, while Green is being used to represent all the wires that will need to be soldered on the top side.

The layout so far - now waiting to see which connections I missed.

In the Rubik's Cube project I used protoboard, a variation on strip board where each pin hole is not connected, whereas in strip board they are connected ... in strips.

Strip board (or Veroboard)

Proto-board (or Matrix Board)

This reduces the amount of soldering required, and number of funny bits of wire on both sides of the board. Both do the same job of acting as a permanent bread board with solder.

I am fairly happy with the design as it is, it is fairly compact (if unable to tessellate nicely in the standard strip board sizes) and appears to have a minimum of random wires running large distances around other components.

The next part of the project is where some of the final hardware products will come together which means things like the power consumption, physical size and usability will move from predictions to measured quantities (or qualities).

--------------------------------------------------------------------------------------------------------------------------
For those following on from my previous post, he documentation has progressed as expected, currently sitting at 40 pages of informational goodness - LaTeX really helps with long documents (no massive document redraw when you move a figure/table/sentence around!). Most of the software has now got full documentation with all of the interfaces specified. The only big things left to do are explain the hardware design (including the beautiful layout above) and some user guides. Hmmm - writing those down made me think that actually those could end up being quite large pieces of work.

The return of Arch Enemy no. 38

DOCUMENTATION.

Like this but PDF.

If ODOTS is to be successful it is a fact of the universe that 'self documenting code' and 'straightforward hardware' are not going to cut it. Not only is explicit recording of all code and components required but an explanation of the various interfaces in the project is also going to be needed to make sure the ODOTS makes sense to a prospective user/builder.

What am I looking for in the Documentation of the ODOTS?

1. Enough information for someone to build and use it from scratch.
2. Enough information for someone to poke around with the design.
3. Enough information for me to return to the design and still know what is going on.

If the ODOTS is to become community developed a solid baseline design is essential. Building extras is easier when the foundation is not made of sludge!

So you may notice that the ODOTS is not actually finished yet, so any documentation written cannot possibly be correct. This is true, there is currently a lull in the design work: I have finished the firmware and now need to move onto a basic making a basic PC based interface and putting together the final proof of concept hardware design. The interface will manage ODOTS checkpoint unit configuration and handle competitor information sorting and retrieving from cards. (I really don't intend to put much more than bare bones functionality into it.) Back to the original point, this lull provides the perfect opportunity to record work so far and tighten up some functionality definitions from random scribblings on my desk.

I have suffered defeat at the hands of Arch Enemy no. 38 before, each time the horror of having to look at your own work and find it indecipherable is enough to make you say 'next time, next time'. Incidentally the Enemy can strike within a single project, recently the Engineers Flat effort to make a custom Robot Wars Control PCB was derailed when we forgot to write down the sequence of resets required to successfully flash the micro controller we were using.

The good news is that there is nothing truly complicated (after development) about the ODOTS so the documentation has so far gone without a problem!

The ODOTS test bed - an example of approximate perfection

HAHA - something that works! (maybe)

So - an exciting day, all individual components have been tested individually. The RFID unit has successfully read and written from both MIFARE 1k and 4k cards, the clock has kept time and had its time set, the buzzer has buzzed and the Microcontroller has sat though it all tolerating my antics. Special mention to the 200mm Telescope which donated one of its off-cuts to the testbed as a back board.

The test bed is really about getting everything together in one place so that it can be worked on as a piece. As mentioned earlier all individual components have been tested to the project from here on out is really about putting it all together, using the clock to generate data to be stored on the card, using the buzzer (and soon to come LED) to indicate to the user operational behaviour and finally building in the magic serial to computer interface that will allow each ODOTS checkpoint device to have its time re-calibrated, its function defined and its ID set.

At this point in the project I have a month and a half (if you squint) before my self imposed deadline which is good as if I can get major functionality done this week I will have a month of poking around, testing (and breaking) before a test-with-public at the end of September and a write up with tutorials by the end of the year. This probably means that it is a good time to look at how the project is tracking against its original objectives. For reference the requirements stated were:

1. Have 100 competitors on a 20 checkpoint course for under £500.
2. Ensure top level designs and software are straightforward and accessible.
3. From a performance standpoint checkpoint registrations should ideally take <20ms at a range of under 0.5m, while competitors should have the ability to record as many checkpoints as possible. Orienteers, being used to current timing systems, will also require the checkpoint registration times to also be recorded to around centi-second accuracy over a course that could take 24 hours!
4. From a safety standpoint it would also be helpful if checkpoints remember who has visited them as this can help with search and rescue (if needed).
5. From an operational standpoint the entire system should still work if it has been submerged for a while in a nice wet bog.

The engineer requires that I address these in the simplest way possible, point by point ("Yes" may be a bit too brief).

1. Cost analysis (a very exciting spread sheet) currently predicts ~£18 per Checkpoint unit (for the proof of concept) and <£1 per competitor recording card. 20x£18 + 100x£1 ≈ £500, so this is probably an achievable goal so far.
2. Arduino libraries are brilliant at keeping you from getting too bogged down in detail, which is generally when the unreadable spaghetti appears. So far the code has been written with the utmost effort to keep relevant variables and constants centralised and accessible. The top level Arduino sketch is currently looking like psuedo-code (because it almost is) but there should be no reason for this to break down. Source code has been split down into device specific headers, or general ODOTS functionality. The proof of concept will be built with through-hole, and widely available, components making it easily replicatable by someone with little specialised tooling or expertise.
3. Very straightforward functional requirements, these will all be met. Choosing the MIFARE standard gives access to 1-4kbytes of storage (100s of controls) with an RF interface that can generally conclude an exchange within 10-20ms at close range. Engimancy with the clock will allow millisecond precision of timing for the same unit and close to that between units, laziness more than anything else limits the available time frame, the clock has records of the current century if needed!
4. This is the only objective that may be bent, memory is at a premium in the AtMega chips, unfortunately this feature may have to wait until the system is made slightly more professional.
5. Lunchboxes and a contactless interface are acting fairly well to keep the entire design pretty easy to keep waterproof. 

Other than final integration big tasks looming on the horizon are dealing with the power situation (especially for the RTC, I am thinking a coin cell hiding behind a diode...) and actually developing my ideas about the enclosure. Also trying to make sure that any user is able to handle the built product intuitively will be good to do. Making an interface for setting Card and Checkpoint IDs as well as changing Checkpoint unit function which is simple as possible with an eye for starting to get it to run on minimalist extra hardware will be a must at some point.

An updated logo, I realised that the antenna is too good
a shape to not include!

Time to think about time....

With the RFID system on a postal adventure for the next few days I decided to give some thought to the T of ODOTS. (It is indeed, T time...)

As a timing system the ODOTS will need to be able to accurately (and to an extent, precisely) track the time at each of the recording stations. The microcontroller unit has the ability to track time to an extent by looking at its own clock (digital signal clock, a simple oscillator) but these tend to be rather inaccurate (because they don't need to be) and also loose track of time when you pull the plug. 

This is where an external clock chip comes in handy both having dedicated hardware ensuring that it is keeping time well, and the ability to run on a very small power supply, allowing it to be powered with a small coin cell while the rest of the system is having a plug-pull induced nap. As mentioned in the last post the proof of concept system is staying in DIP land to reduce required soldering complexity/need for PCBs, on top of this requirement I also wanted the chip to require a minimum of external components. Luckily the handiest chip to use is Maxim's DS1337(+) a brilliant little chip that not only satisfies my generational requirement to meme, but also already has drivers written for it (though I only learned this after getting halfway through writing my own).

Choosing the RTC with the power of 1337.

RTC (Real Time Clock) time will be synchronised with a computer, probably during initial setup and then periodically by some sort of Tech Wiz (capitals necessary), while the microcontroller will periodically re-align its own time estimate with the RTC's during operation. Ideally the update timing slack will be less than 10ms (about the maximum precision I could really expect from the RFID system). The RTC can generate interrupts on second boundaries (effectively showing the 0ms point for that second) which I will be exploiting to allow the Microcontroller to gain some sort of sub-second accuracy. 

The frequency of RTC referrals is interesting, ideally I want to keep the interval small (to prevent inaccuracy buildup), but not so small that referring to the RTC is the only thing the MCU has any time time to do. Initially I had thought 10 minutes would be good, but this would require the Microcontroller to set the next interrupt time after each referral, increasing the time each refferal takes. However, the RTC has inbuilt repeating alarm abilities, once every unit of time (once a second, once a minute e.c.t.) for the time being I will attempt to use the once a minute interrupt to see if this noticeably impacts performance for users. That throws as many 'this is going to cause more work in the future' flags as I have seen but oh well....

Standard Struggle (or how I learned to stop worrying and love NXP)

Part of the ODOTS project is about tackling the problems that other people wont want to, and I think that I have taken a month to do just that. Today I finally admitted defeat to NXP - if I want the ODOTS competitor timing cad to be a MIFARE device (which I do, they are ubiquitous, diverse and likely to be around for a while) I am going to need to use their Reader/Writer ICs. The bit that finally pushed me over the edge was the realisation that not using an NXP chip was going to doom me to having to run the authentication and encryption on the Micro-controller. A day of searching for a friendly application note/datasheet/tutorial showed up nothing.

Up to this point I had mostly worked out the firmware for the CR95HF (from ST Micro) up to the ISO14443a layer and was feeling like I was understanding how it all hung together (a good indication that you are about 10% of the way there). Unfortunately while the CR95HF is MIFARE Classic compliant it requires encryption and authentication to be handled by the host (the micro-controller), while NXP chips will take the bulk of the work off you conveniently meaning the task of encryption and authentication are not often tackled by the sorts of people that will leave behind handy code libraries and examples. Thus I could continue to try and write code to run MIFARE tags through the CR95HF, but it would be a significant piece of work with little benefit (in the short term) over just using an NXP device.

The beaten track beckons, so I am flipping into complete Arduino-friendly mode and using the MRFC522 chip that has a development board that has been mass produced to the point that you can pick them up for £5 from mystery-meat ebay and amazon sellers. My development article is coming from a more reputable source in the hope that it allows me to avoid the classic block-of-resin-with-solder-pads knockoff syndrome! With all RF and surface mount components handled by the wonder board most other components are going to be possible to do with through hole components (or DIP) - for that sweet sweet 90s look. this will also make it more straightforward to prototype and 'mass' produce proof of concept timing units for demonstrations. Naturally as the likelihood of the ODOTS actually being used goes up the more and more it will approach a single PCB, all surface mount, state. Additionally using a shady source RF board may make it tricky to prove that the device is not producing large amounts of EMI - so it will need to be replaced at some point.

Astro Meandering

It has been a while since my last astronomy post, having to spend all night studying tends to reduce sky watching activities. There have been several developments however.

The 200mm telescope has proved itself as a semi portable device, it was successfully dismantled and transported to Scotland by car where it was reconstructed with no ill effects. The de/construction process takes about 15 minutes and appears with not really change the required mirror tilts for columnation. The telescope was not actually used up there ( :( ) as Scotland in summer only really gets dark in the morning and the trip to Scotland was actually for an Orienteering carnival - something that generally requires the maximum amount of sleep possible!

One deconstruction/construction cycle later and the scope is now working back down south. I took it out for a quick test last night, the forecast promising clear sky and the moon offering a good target for finder alignment and focus testing. Of course the forecast did not include the predictable appearance of thin high altitude clouds after such a warm day so I only got to looking at the moon and a brief look at Andromeda before everything became obscured.

With a nice full(ish) moon I also had the opportunity to  test out my new phone's camera and the darkening filter I have had in my eyepiece box forever. I have put the nicest photos below, but be warned my skills are still low, I have yet to get the exposure settings right, and I really need to come up with a way of holding the phone that is not my hands so that I can fix the positioning of the camera aperture. There is however a marked improvement over using my old phone (not surprising) or the mighty 76 millimeters of the Drinking Straw, though I think the latter is more to do with mow much more stable the 200mm's mount is!

A full moon in a single image, showing some nice detail on the terminator (to the left).

No Moon-photograph session is complete without a photo of Tycho Crater.