Tuesday 15 November 2016

John Lewis Sale! Huge Reductions in Ethics!


The StopFundingHate campaign is a new(ish) approach to an old problem. Both personally and professionally, I have long believed that success should not be to the detriment of the greater good.

As a family, we try to make conscious purchase decisions based on the ethics of brands. This can be a challenge because most of the large high street brands have a somewhat spotty record. The primary exceptions are the John Lewis Partnership and the Co-op, both of which have/have had their issues, but overall have a fair ethical compass.

Yet:

From this tweet (and apparently a full online ad campaign with the Daily Mail), John Lewis appear to be comfortable to set aside their ethics when it suits them.

If a supplier of (say) lamp shades to John Lewis encouraged hatred towards a minority or persistently lied to John Lewis customers (the local community), would stores continue to sell products sourced from a supplier that clearly contravened the ethical policy?

I think we know the answer to that one. Yet they still stock the Daily Mail, Express and Sun.

Newspapers also provide an advertising service to John Lewis. They are a 'supplier of goods [or services] not for resale'.

The John Lewis ethical policies page is very clear. The text next to link for Sourcing Responsibly it reads:
Rule 96: 'The Partnership’s relationships with its suppliers must be based on honesty, fairness, courtesy...'
And if you look into the constitution[pdf], Rule 96 continues:
'...and promptness. It looks for a similar attitude throughout its supply chains. In particular, the Partnership expects its suppliers to obey the law and to respect the wellbeing of their employees, their local communities and the environment'
In the Responsible Sourcing Code of Practice Goods Not For Resale[pdf]) we have the following statement:
We seek to work with companies who share similar ethical standards and values to ours and who will commit themselves to meeting the requirements of this Code. We are committed to working with suppliers to support necessary improvements that will enable a supplier to meet the requirements of the code but we may also take action if they subsequently do not.

So, John Lewis has a constitution that states it seeks to work with companies that share its ethical values and may also take action if those ethical values are not shared.

Does the the Daily Mail, Daily Express and Sun share the same ethical values as John Lewis?

Or does John Lewis share the same ethical values as the hate mongering side of the UK press?

This is key. No one expects advertisers to make editorial judgements, even though they do this already (would you see a John Lewis advert in a top shelf magazine?).

We do (or should) expect them to make ethical judgements.

John Lewis has chosen not to act against its published constitution and ethical code of practice.

The John Lewis Partnership can either be an ethical company or can be a company that chooses to fund the promotion of hatred.

It can't be both.

Friday 24 June 2016

Surrendering to the Politics of Fear and Hate

I was woken this morning at 04:22 to by a very cheerful blackbird. A brief glance at the news told me today was anything but cheerful.

24th June 2016. The day the United Kingdom became Little Britain.

So how did it come to this?

It was all too easy for the Leave 'campaign'.

At a time of ideologically imposed austerity, ensuring services are cut to the bone, the NHS is underfunded to breaking point, jobs are insecure and low paid, it was an easy lie to tell:

Everything is the fault of the EU.
And, so it seems, as a nation, we fell for it.

Why should that be a surprise? We've accepted the normalisation of 1000+% interests rates on loans when the base rate is 0.5%. We blame the financial woes of the nation on poor people, indifferent to the illegal/immoral activity in the banking sector.  We've been duped into believing our self esteem is based on the 3 ton vehicle we drag our sorry inadequate arses around in.

How easy was it to persuade the nation it was all the fault of 'immigration'? Too easy.  With its very real issues that need addressing, the EU was a convenient scapegoat.

What happened to the Remain 'campaign'? They were stuck between a rock and a hard place:

They could not tell the truth.
From the 1980s (and probably before), politicians have prioritised profit over people. We've had successive governments that have handed tax receipts and control to entities who's sole concern is simply maximising their profit. From deregulation to privatisation/profitisation, politicians served business before people.

How could a government who's doctrine of austerity created the discontent in the UK put their hands up and say: "It's our fault you can't get an appointment with your GP because we've cut 20% from the NHS budget. It's our fault your roads are potholed, because we have we have capped council tax."?

They could not tell the truth. In trying to pacify extreme elements in his party, David Cameron unleashed a wave of discontent of his own making.

We will reap the seeds that have been sown. This referendum has normalised lies, hate, fear, xenophobia, racism and bigotry in political and public discourse.

What happens when the leave voters realise they have been lied to? When that £350 million per week fails to materialise into the NHS, when services are still being cut because public funds become private profit?

Who will we blame?

We are Little Britain.

Wednesday 22 June 2016

Resisting the Politics of Hate and Fear

This post has lain in the drafts folder for a while now, but the events of the last few weeks have motivated me to get this off my chest.

There is a strange parallel between the nearmiss-o-meter project and the UK's EU 'referendum'. Bear with me.

The nearmiss-o-meter project has been a great education for me. I've (re)learnt about electronic circuits, sound, Arduino, designing PCBs, 3D printing, how bad I am at soldering small things... The list is huge.

But would you like to know what the biggest education has been?

People's reaction to it. In a strange foretelling of the EU referendum, after describing its function, the first response of far too many people has been to spew vitriol that has absolutely no basis in fact.

Shocked? A little. Disappointed? Absolutely. Some of these people I've known a long time (and used to respect their opinions).

So why do people on bikes or the question of whether or not the EU is a good thing engender such a responses?

Our transport infrastructure systematically prioritises motor vehicles. Successive governments have chosen to make us dependent upon the most inefficient form of transport. This is a deliberate political choice. The question has to be asked, why is our government not working for the greater good?

Similarly, successive government policies have ensured our economy will benefit a few in the short term, but with little regard for the damage it causes to the fabric of our society. Middle incomes are barely affected, but while wealth at the top is still growing during a time of alleged 'austerity', the numbers of children living in poverty grows alarmingly.

These are political choices. As history shows us, the economy will be the economy, the only difference politics makes is the distribution of wealth.

So when a 'cyclists' holds up a 'driver' for a few seconds, they become the scapegoat for a politically chosen transport infrastructure that will never deliver on its promises.

The answer to any question regarding urban mobility is never:
"Add more cars"
Yet that is the default response from politicians desperate to remain in power.

We have become a society where the death of a person on our roads results in a few points on your licence.

This is normal. The police, CPS, judges and juries feel empathy with the driver, not with the victim: "It could have been me who killed that mother/father/son/daughter. That would be awful [for me]."

When jobs are in short supply, or too poorly paid to feed and home a family without support, when public services are underfunded, you can't get an GP appointment etc, etc, it is easy to blame free movement of EU citizens. Yet the vast majority of immigration is from outside of the EU - under complete and utter control of the UK government.

It is a political choice to allow immigration. Why? Because it is good for the economy.

It is a political choice to underfund essential services whilst supporting vanity projects. We each make a political choice to 'save' a few hundred pounds a year in council tax whilst grumbling about potholes. We elect politicians who enable multi-nationals to eschew their tax liability altogether, yet we buy from Amazon, Boots, Cafe Nero while they take from, but never give back to our economy.

Our membership of the EU affects so little of the above. They are all political choices made solely by our elected government and its sponsors.

We have a media that demonises minority groups, based on religion, place of birth or mode of transport, yet we continue to fund the hateful policies of those proprietors by buying their newspapers. Even supposed 'unbiased' media outlets give voice to unfounded hateful rhetoric in the name of 'balance'.

The assassination of Jo Cox was a predictable outcome from the never ending vitriol that spews from our media and so many politicians. Hateful rhetoric has real consequences. As a 'civilised' society we have a duty to educate not indoctrinate, yet the ease with which so many are persuaded with lies suggests our education system has failed to teach critical thinking.

Do I have answers? No. Will I try harder to make a difference? Yes.

I am a grown man and I have no qualms in admitting I shed tears when listening to those who paid tribute to Jo Cox, a mother, daughter, sister and politician, so will leave you with her words:

"We are far more united and have far more in common with each other than things that divide us."

Do not let the hate win.





Wednesday 11 May 2016

Nearmiss-o-meter, The Difficult Second Album

It's been a little while since the last update. Who'd have thought product development could take so long?

Snorkel Design

The original design.
I've been chasing down a few minor frustrations with the first complete version of the Nearmiss-o-meter.

The first was caused by the design of the snorkel, causing a resonance similar to blowing across the top of a bottle. This in turn 'blinded' the sonar in gusty conditions.

A redesign for the original box, similar to the original cardboard concept resolved this and I have now also redesigned the case to allow interchangeable snorkels of different lengths.

Only measures 6cm...?
It works...
However, a very minor change to the snorkel throat for the new box introduced an echo that meant the sonar read only 6cm!

Spot the difference.


GPS Checksum Errors

The second major issue was a little harder to track down. Periodically, the GPS appeared to stop reporting. A bit of debugging later, and this was tracked down to TinyGPS complaining about an invalid checksum. Most GPS devices (such as the uBlox) send out information as NMEA sentences, which includes a checksum at the end. Both the uBlox and the TinyGPS library are very mature and when I ran them in isolate test, I could not replicate the error. So the bug was very likely in my implementation.

Intermittent issues are always tricky. The key to squashing any software bug is to be able to replicate it reliably, but the the GPS lockups seemed to be random. It would track perfectly for long periods, then stop for 20 seconds, then continue normally, stop, continue etc. Very frustrating.

After eliminating any issues with my code, I started thinking about timing and buffers. The uBlox delivers all the NMEA sentences in one burst. These sentences are only a single line, each of less that 80 characters, but they are all delivered at once, on the epoch of each second (i.e. 1Hz) That's not a lot of data to consume for your average PC, but the Arduino has a default serial buffer of just 64 bytes.

The initial fix was to reduced the number of NMEA messages to just the bare minimum and counter intuitively use a slower baud rate. This seemed to help, but did not solve the problem completely. If the Arduino 'loop' strayed out of sync (i.e. was not ready to read the buffer at the epoch) then the serial buffer would overflow and TinyGPS would not have a valid checksum.

The next step was to investigate increasing the serial buffer. I wanted to avoid this as it cannot be done in the sketch and is different for every type of board, which complicates other peoples setup but it had to be done.

Board Upgrade

In the process of trying to debug all this, I switched from the 32u4 version of the Adafruit Feather moving up to the M0 - a whole 256Kb! The 32Kb limit (actually 28Kb of code)meant I was spending much of my time reducing the size of the code rather than building the functionality I wanted. The Feather M0 is physically identical (thank you Adafruit) but quite different to code for. Most Arduino libraries will run fine but crucially, not the SoftwareSerial. Oh Pooh, said Piglet. We need that for the sonar. Don't worry said Lady Ada, use SERCOM! If you really want to get down & dirty, read this excellent tutorial on muxing and serial SERCOM. I cannot praise Adafruit enough for their documentation.

Serial Sonar Modulation

Moving swiftly on, I then needed to address the serial sonar library. If no object was detected within 8 metres, the sonar firmware would take almost a 10th of a second to respond to a single 'ping'. This is not good when you're attempting to read the median of five pings, five times a second. No amount of messaging would persuade it to abort mid ping, so I have implemented a 'modulating' median ping. The library will do as many reads as it can (up to 5) within a given time frame and then return the median. Sorted.

New stuff

Moving to the M0 allowed me to build in the following functionality:

  • Greater 'accuracy' for lon/lat recording using the TinyGPS++ library. See this excellent reply for further information. We are now recording 6 decimal places - this does not mean the lon/lat will be accurate to 11cm, but is does mean the trace will be smoother.
  • A config.txt file on the SD card to allow end users to change the Nearmiss-o-meter behaviour without having to recompile and reload to the Arduino. e.g. sonar offset, timezone etc.
  • Date/time stamps for files. It didn't bother me too much, but seemed very peculiar to see files dated 01-01-1970... We are still limited to 8.3 file names, but the config.txt above allows both the filename and the timestamp to be in local time rather than GMT.

Disable vs Isolate

For the first version, I simply isolated the battery with a switch. This is the 'better safe than sorry' approach, but it means you would have to switch on the nearmiss-o-meter in order to charge it. Not very user friendly. Adafruit have implemented an unintuitively named ENable pin. If this pin is grounded (it is held high internally), the 3v3 regulator is disabled thereby shutting down the processor and the peripherals. A bit of measuring of the 'quiescent current' with a friends highly sensitive meter and a bit of maths told us the battery would last more than a month in standby mode. I am still chasing down an oddity whereby I can read 0.8 volts between 3v3 and GND when in disable mode...

Other stuff

I've also created a small handlebar button comprising three components (and took a surprising amount of time to design...). This makes it much easier to start/stop recording and 'tag' near misses.

This now has just two LED (red for GPS and green for recording) as the multiple colours did not aid readability. The blue nearmiss/testing LED has moved to shine out of the snorkel along with the light sensor to auto dim the LEDs.

So it is still a work in progress... I hope to have a PCB design ready to send off soon & then perhaps make a couple of boxes for interested parties/patrons to test :-)

Update #1

The Arduino code & Eagle (Gerber) files etc will be published on Github.

The logic behind creating a couple of test units is to ensure other people don't waste their time/money/efforts on something that doesn't work as expected. An example of this is the use of various pins on the Arduino - I've learnt that some can do PWM (for dimming LEDs), others can not. The same for the SERCOM pins.

The second reason for the test units is to prove the usability of the design (developers of software and or physical products are the last people you should choose to do testing) and also to start to understand how the data can be collected/collated/validated etc.





Tuesday 8 March 2016

Near-miss-o-meter, Arduino Code



A short post to describe the functionality implemented in the initial release of the Arduino software on github. This is the first Arduino/C code I have written, so feedback is more than welcome. It is has been an interesting challenge to get all the things I'd wanted into just 28kB of space. Avoiding the use of floating point numbers in TinyGPS meant I had to take on sprintf (and I won, albeit at 2am!).

The code is structured to allow for easy adaptation to other boards and sonars, so tends to use 'global' variables more than usual. The initial version, built for the Adafruit Feather 32u4 Adalogger, will support 'pulse output' sonars via NewPing and serial output sonars via SerialPing (my first Arduino library, be kind).

The choice of sonars is slightly limited by the Feather running at 3.3 volts, so the ultra-cheap ones such as the HC-SR04 will require either a voltage booster or a 5 volt board. The cheaper serial sonars will run at 3.3 volts.

User interface

The nearmiss-o-meter has an extremely simple user interface, consisting of  three LEDs:
  • Red LED: GPS and battery status.
  • Green LED: Record and tagging status
  • Blue LED: Nearmiss and 'test mode' status
and one push button (momentary) switch:
  • Medium press: Start/stop recording
  • Short press: Start stop tagging (if recording)
  • Long press: Start/stop test mode (will ping sonar without a GPS fix)

What does it do?


Power Up

When the Arduino is powered on, the green LED will flash twice if the SD card is present. The red LED will remain fully lit until a GPS fix is obtained, at which point it will show one short flash per second.

Start/Stop Recording

A medium press on the switch (greater than half a second) will start recording if there is a GPS fix. The green LED will light fully when you have pressed for long enough and when released will show one short flash per second to indicate recording.

Recording is stopped in the same way (even without a GPS fix).

Files are recorded in the root directory of the SD card named in the format YYMMDDHH.csv. Note: the standard Arduino SD library does not support file timestamps so all files will appear to be created on 01/01/1970.

The CSV record consists of:
  1. Date/time in ISO ISO 8601 format (UTC)
  2. Longitude, to 4 decimal places
  3. Latitude, to 4 decimal places
  4. Speed, in kph
  5. Course or heading, in whole degrees
  6. Passing distance, minus offset (if specified)
  7. Tag state, either 0 or 1

Tagging

When recording, the nearmiss-on-meter will log a continuous trace, so the design also allows for continuous tagging (perhaps to denote sections of cycletrack). The switch implements a 'press to toggle tagging' rather than 'press and hold to tag'.

A short press (less than half a second) will start or stop tagging.

The green LED will show two short flashes per second while tagging.

Test Mode

A long press (greater than 5 seconds) will enter/exit test mode, irrespective of whether a GPS fix has been obtained. The CSV data will be sent to the serial monitor (via USB) of the Arduino IDE.

Source Code

The initial release of the source code is here. It is fairly well documented, with links to all the required libraries. Instructions for setting up and using the Arduino IDE are here

Have fun!

Part 5: The Difficult Second Album

Wednesday 24 February 2016

The Near-miss-o-meter, Part 3

From Breadboard to Pegboard

A slightly longer delay from the last post than planned. Partially due to my slow wordsmithing, but primarily due to the distraction of writing smart phone version as a 'cheap-as-chips' nearmiss-o-meter. More on that later.

Rendering in the most compact form.
This post will document the build of the standalone Arduino prototype. This could be packaged either on a custom PCB or home brewed onto a peg board within ~50mm x ~50mm x ~40mm cube (including battery).

The test version I have created is single sided (for ease of wiring), has 8mm high sockets (to enable me to re-use the components) and still only measures 50mm x 70mm x 45mm. It also includes a 3.5mm mono headphone socket for a remote switch.

Please note: All the information here is for guidance only. If you're unsure of what you're doing, please get someone qualified to help (i.e. not me!). Most of the components are fairly benign (although if you accidentally connect a 3.3 volt LED to the 5v USB input, it'll blow the top off and hit you on the forehead...), but the battery stores a lot of energy and must be treated with utmost respect.

Remember, electronic components run on magic smoke - when the smoke is released, they won't work.

The list of components is as follows:
  1. Adafruit Feather 32u4 Data Logger [>]
  2. Ublox NEO-7M GPS [>]
  3. Maxbotis Maxsonar [>]
  4. SPDT PCB Slide Switch [>]
  5. SPST Push Button Momentary PCB switch. [>]
  6. RGB LED 3.3v [>]
  7. 500mAh LiPo battery (optional) [>]
  8. 50mm x 70mm Double sided prototype board [>]
  9. 3.5mm Mono headphone socket (optional) [>]
  10. Square pin header sockets (optional) [>]
  11. JST connector(s) (optional, but the one on the battery will be wrong) [>]
The links to eBay listings are not necessarily recommendations (I'm not a great eBayer...), they were simply chosen as UK based suppliers. The links may also have expired! If you are willing to buy direct (usually from China), prices could be significantly lower. That said, I have had excellent service from all the vendors - some have been above and beyond expectations. If there is enough interest, I may try to put a 'kit of parts' together with one of the vendors.

The headers (10) and the JST connectors (11) can be omitted if you're brave enough to solder the components directly to the peg board. The LiPo battery is optional if you're happy to power via the USB with a phone charger battery.

You will also need to beg, steal or borrow a soldering iron with a very small tip, a small amount of 0.2mm2 solid core insulated wire and a blob of Blu-Tack to stop the GPS module wobbling (it should really be screwed down).

This is quite a lot more expensive than planned, so since building this, I have acquired a few more ultrasonic rangefinders (and one infra-red one) for testing. All of them are much cheaper than the Maxbotix one and two of them have built in temperature compensation in serial mode, so may be better suited. The limitation is the Adafruit Feather board runs at 3v3, which rules out the 99p HC-SR04. I will write a sonar/board comparison post(s) as soon as time allows.

3D Modelling

Rendering with header sockets and pegboard.
To model the interaction of the components, I used a brilliant open source modelling tool called OpenSCAD.

Even (especially?) if you have never used a 3D program before and have the merest hint of programming or scripting knowledge, give OpenSCAD a try. I have created 3d models of each of the components which I will also upload to Github.

The picture to the right shows my double-sided modelling but as it was my first attempt, I swapped to single sided as I started to solder up. I later learnt you're supposed to do all the wiring on the opposite side to the components. It would probably be neater than my efforts. The PCB image from the previous post shows how to wire it up if you're so inclined.

This is the end result. All I need now is a box, a way of mounting it and the remote switch.

 

Coding for Arduino

The open source/Free software & hardware community really is a gift that keeps on giving. Without all the contributions of so many, this project would not have been possible.

Not only are the specifications of the Arduino hardware open source (which is why you can buy such cheap clones), the IDE (Integrated Development Environment) used to program the Arduino is also freely downloadable. It ships with a *huge* number of example 'sketches' - each and every new library has examples included.

'Proper' embedded programming is new to me. Although I do some embedded Linux, my bread & butter has been enterprise scale databases.  This was going to be a whole new experience. From terabytes to less than 32Kb. Oh my!

Here's the Arduino coding 101: There are just two main parts to an Arduino sketch - the setup() function, which runs once when you power on and the loop() function which runs over and over again until you power off or make the code barf (even then it seems to detect this and restart itself). This makes simple stuff really simple. You want to flash an LED? OK, turn it on, delay 1 second, turn it off, delay 1 second, rinse & repeat:

// From the Blink example:
void loop() {
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second
}


Great. Or not so great. While you're delay()-ing, nothing else happens. If your GPS is reporting a position change, you're not going to see it, if your want to ping the sonar - it's not going to happen.

A 'normal' computer handles all of this behind the scenes. As a programmer, if you want a process to not interrupt your user interface, you spawn it off into a different 'thread' that runs in the background - the operating system then 'schedules' all the threads for you. If you're really scaling, you can spawn it off to a whole new datacentre... Not on the Arduino. You have one loop.

Building a simple state machine

Vanilla Arduinos do not do threads (although guess what, there is a library or two for that!), but it does have a number of internal timers. You can obtain the number of milliseconds (or microseconds) since your program started. If you now define how frequently you'd like to turn the LED on or off, you can count the number of milliseconds that have passed then take an action. But while you're counting, you can do other things.

//Pseudo code
void loop() {
  now = millis(); //Get the number of milliseconds since program start
  if (now - previousOnOff >= 1000) { // If one second has passed

    if (ledState == LED_OFF) { // If the LED is OFF...
      digitalWrite(13, HIGH);  // then turn it ON
      ledState = LED_ON;       // and record the state
    }
    if (ledState == LED_ON) { // If the LED is ON...
      digitalWrite(13, LOW);  // then turn it OFF
      ledState = LED_OFF;     // and record the state
    }
    previousOnOff = now; //Save the time we last turned the LED on or off
  }

  //Here we can do other things
  //. . .
  //And even more things 
  //. . .
}

There is a surprising amount of functionality required that has to fit into just over 28kB. Looking through the code now, I have implemented the following:

GPS Read

Using the TinyGPS library, the location is read via serial, once per second. This is the default transmit rate for most GPS modules. The rate can be changed but the setup codes appear to be different for each version, so it went in the 'too hard' pile. Once per second works well, but the code is designed to cope with faster or slower updates.

From the GPS data, in addition to longitude, latitude, heading and speed, we also get the (very precise) time, which we use for both logging and to create the name of the log file.

When we do not have a fix, the raw NMEA data is sent to the USB serial port for debugging. The red LED will remain lit until a fix is found (or subsequently lost), then flashes once per second.

Sonar Ping

With a little empirical research, I settled on a 'sonar heartbeat' of once every 200 milliseconds. This ensures even fast passes are caught but gives sufficient time for other functions to happen. Each 'ping' is derived from the median of 5 rapid pings to remove outliers, handled by the NewPing library. I have also written my first Arduino library for the two serial sonars which is partially API compatible with NewPing. This means it will only require changes to a couple of lines of code to switch between different sonar modules.

If a near miss occurs (less than one metre), the blue LED will flash rapidly until we have 5 clear pings. This also gives an indication if the sonar is blocked or has barfed and can be used to check calibration.

Write to SD Card

Arduino has two libraries to support SD cards (SPI and SD) which take care of most of the heavy lifting. One minor limitation is the 8.3 file name format (MSDOS is still biting us on the bum), so I settled for YYMMDDHH.csv. If a file already exists, it will be appended. The data is written after each ping but only flushed once every two seconds to reduce battery consumption.

On startup, the presence of the SD card is checked and the green LED flashed twice to confirm. When recording there will be one short flash per second. If a file open or write error occurs, then there will be two long flashes per second.

Flashing the LEDs

To provide an easier interpretation of status, I've used a RGB LED. I've implemented a design that splits each second into 8 segments allowing each state to be indicated by each LED without clashing. The patterns are easy to update and 'visual' in the code:

const byte GPS_NO_FIX    = B11111111; // Continuous
const byte GPS_HAVE_FIX  = B00000100; // Once per second
const byte RECORD_ERROR  = B11101110; // Long flash, twice per second
const byte RECORDING     = B00000001; // Once per second
const byte TAGGING       = B00010000; // Twice per second (in combination with RECORDING
const byte NEAR_MISS     = B10101010; // Four times per second
const byte LOW_BATTERY   = B01010101; // Four times per second OR'd with GPS_HAVE_FIX


These constants also serve as status values, saving a few essential bytes.

Single switch control

The push button implements a medium press for record on/off and a short press for tagging on/off. It could also implement a long press if required. A side effect of the implementation also deals with the 'debouncing' of the switch contacts. No, I'd never heard of it either!

Battery State

This small but essential indicator was the final piece that I was able to squeeze in. On compile I now get the message:

Sketch uses 28,096 bytes (97%) of program storage space. Maximum is 28,672 bytes.

It has taken some effort to trim the code to fit - so although quite functional, it is currently in need of a bit of tidying...

Next Steps

I'm currently learning/working on an Android OTG version, which will significantly reduce the cost of the primary parts. The phone will provide the GPS, logging and power, with the slight downside of a cable connection. Logging to the phone should also enable easier uploads of the data and may provide a basis for a Bluetooth version. However, this is incredibly distracting (read: time consuming) so have not yet started the Github learning curve...

Part 4: The Arduino Code

Thursday 4 February 2016

The Near-miss-o-meter, Part 2

This post documents the route I took to arrive at the current configuration of the nearmiss-meter, so you don't have to.

The Digispark in my previous post introduced me to the Arduino family, but with only 8kB of memory it was never likely to have the capacity to process both GPS and sonar data and write it to an SD card. Arduino is not a technology I had played with before starting this project but turns out it is really easy to set up and get going. The 'Blink' sketch is the Arduino equivalent of the ubiquitous 'Hello World' of every programming language ever invented - one of many, many examples that come with the freely downloadable IDE.
En route to the Pantomime on Christmas Eve, we detoured via Maplin picked up an Arduino/Genuino Micro. This comes with a heady 32kB rather than the 8KB of the Digispark.
Adruino Micro, HC-SR04, USB GPS & SD card
Once the festivities subsided a little, I pulled together my collection of components and realised I couldn't just plug the USB GPS into the Arduino. I also couldn't justify (or wait for) a PCB GPS so after a glass or two of brain lubrication I started to cobble together a Python script to read the GPS via my PC USB port, spit it out of another USB port to the Arduino and also read back from the Ardino... Easy peasy eh?

It turns out Python blocks when it reads/writes to/from a serial port so I had to lean about Python threading. Then I had to learn about how you can Ctrl-C from a Python thread so I didn't have to keep manually killing the process! (As an aside, I also learnt enough Python to control my half price Maplin 433MHz remote sockets from my Pi. I'm easily entertained...)

There are a huge number of libraries for Arduino, so the chances are, if you want to do something, someone has probably done it already (and than made a library out of it). NewPing was the first library I 'discovered', when I setup the Digispark. This library does all the complicated stuff for ultrasonic sensors so I don't have to.

Next up was TinyGps, a small but perfectly formed library for parsing NMEA [pdf] data (this is a standard set of strings or 'sentences' that most GPS devices spit out). The sensor built by Dr Ian Walker used a combined Real Time Clock (RTC) and data logging shield. Microcontrollers (and the Raspberry Pi) do not have a RTC so do not know or store the current date and time. The Pi often gets its time from ntp when it boots up, but this requires a network connection. With a GPS we can get the exact time - down to the nano second!

By default, most GPS devices output location data once per second. It is possible to reconfigure the frequency, but the setup strings are not standardised across devices so I've left this alone for now. We definitely want more frequent readings from the sonar and after a little trial and error, I settled on a 'sonar heartbeat' of five times a second. This should not swamp the SD card and will also give sufficient time to get a median reading from multiple 'pings'.

Meanwhile, an SD card board had arrived, so I gingerly plugged it in. The repeated dire warning in many of the pieces of documentation I'd read about SD cards was: "Don't use 5v, anything more than 3v3 will fry your card.". The board I'd bought was listed as running on 3 or 5v, but I suspect I'd not be the first person who bought something from eBay that wasn't quite as described...

I tested with some old/broken SD cards and when they didn't smoke I put in the one and only spare I had. The example scripts for Arduino are brilliant.

I now had a working prototype, albeit with a laptop attached, so I stood at the side of the road and tested of the rudimentary setup. Thoughts turned to power supplies and charging - this Arduino Micro is 5v, so to power it on the move I would need either a portable USB charger or a LiPo battery + a step-up booster + a charging circuit. More components, more complexity. The USB battery is definitely an option when I revisit the Pi version, but for ease of shareing, the unit really needed to be self-contained. Enter the Adafruit Feather  Adalogger.

This featherweight microprocessor had an on board SD card and built-in battery charging. The only downside was it ran at 3.3 volts whilst the cheap HC-SR04 sonars run at 5v. However, it removed the need for several components with just the step up booster required.

With a new breadboard circuit made up, including the newly arrived Ubox GPS board, I now had my first fully portable system. Two resistors gave me the step down for the returned echo from 5v to 3v3.

I'd also ordered a couple more cheap sonars - I wanted to see how consistent their measuring was, but I couldn't get the two new ones to work. It seems not all HC-SR04s are created equal. Some will trigger with 3v3, others absolutely require 5v. Not happy. This would mean having a logic level shifter (new to me too!) - yet another component.

On the plus side, the Adafruit Feather performed well, despite only running at 8MHz but it was time to bite the bullet and buy a more expensive sonar that ran at 3v3. This is the Maxsonar MB1010, from Maxbotix. They have a huge range of sonars for every application, but my choice was based on price and easy availability in the UK as well as noting Ian Walkers use and comments. The top end fully waterproof models are way out of the target price range for this project, but may appeal to some who want to log data in all weather.

A couple of (late) nights later, with the great Antoine de Saint Exupéry sitting on my shoulder, I had reduced the design to the minimum: a single sided PCB with just three main components. Although this design is operational on a breadboard, this PCB layout is currently untested as my local PCB fabricator wanted to charge me £800 'consultation' fee before looking at it! The next step is to implement this on a peg board, to improve the connection reloability of the prototype, then I'll probably use Fritzing to get a test board made up.

Other than the plethora of new new things I've learnt, one of the biggest personal benefits of this project was that for almost the whole of the Christmas and New Year period I watched very little television but we're back into the swing of work/life, time is a little more limited.

I now have the Arduino code mostly written and a rudimentary Leaflet based web 'viewer' of the data.

This is a local street on the way back from my local bike shop that is absolutely awful to cycle along. The colour grading of the line shows red for less than 1m and shades from red to yellow to green for 1m to 2m passing distances. The data is only ever held locally (using Javascript FileReader), so privacy is ensured.

The next post will document the device I have prototyped in greater detail, along with the functionality implemented in the Arduino code. I have created a Github repository, but that is another learning curve I need to overcome before I populate it.


Part 3: Breadboard to Pegboard





Thursday 14 January 2016

The Near-miss-o-meter, Part 1

It all started with this tweet from @beztweets:
with a link to this great post by Dr. Ian Walker. I'd seen a few of these previously (whenever a '3 foot rule' is introduced somewhere) but the suggested addition of a GPS seemed to make sense, possibly for the Near Miss Project run annually by Dr. Rachael Aldred and Emily Brooke.

Coincidentally, I was about to receive my Raspberry Pi Zero on the front of the MagPi magazine. It seemed like a perfect match: a few days off for Christmas, a £4.00 computer, a £10.49 USB GPS (you can get them cheaper if you're will ing to wait for shipping from China) and a £1.61 ultrasonic sonar (HC-SR04) from that auction site.

The Aim

To create and document a compact design that can be built by anyone using easily available components without requiring a huge amount of technical knowledge. Although I played a little with electronics as a teenager, my knowledge is pretty much limited to knowing the difference between a capacitor and a resistor. I do like a challenge.

This is the first of several posts that will briefly document the journey and finish up with a more detailed 'howto' of a reference design.

Prototype 1: Pi, USB GPS, Sonar


After a mad run up to Christmas, I had half a day free, so started playing. Hooking up the Pi to a breadboard and wiring in the sonar is well documented on the web (e.g. here). Major lesson learnt here was how to drop 5 volts (from the HC-SR04) down to 3.3 volts (also known as 3V3, the maximum voltage allowed by the input pins on the Pi) using two resistors (or any three resistors of the same value using two in series).

With the USB GPS plugged into a powered hub, we were away!

Not quite. The Pi works very well with the sonar as long as that is all it is doing. The HC-SR04 works by setting the ECHO pin 'high' for the length of time it takes for the ultrasound 'ping' to bounce to and from its target, but if you start to add any logic into the measuring process, the Pi wanders off to do other things and forgets to listen to the ECHO pin for a few nano seconds. This results in frequent over-long distance measurements.

Thankfully, I'd done a bit of reading, so it was quickly on to:

Prototype 2: Pi, USB GPS, Digispark+Sonar


A Digispark? No, I hadn't heard of them either. They are a tiny, USB powered Arduino. About the size of a postage stamp and costing all of £2.99 on eBay. Unlike the Pi, this is a realtime microprocessor (with 8kb of memory!).

Shamefully, I'd not yet played with an Arduino before so there was a small learning curve to get up to speed. This excellent post, meant the Digispark was quickly wired to the sonar and plugged into the Pi.

Digispark + HC-SR04
Success! Consistent distance readings now being recorded with lon/lat, time, heading and speed from the GPS. Here we have a complete (hardware) solution for less than £20 (plus a USB booster battery to power the Pi on the go).

There was one minor issue: all the data was being recorded onto the Pi's SD card. This is fine for me (we have been 100% Microsoft free since 1997...) but a Windows PC cannot read the Linux Ext4 file system on the card without installing additional software. It is theoretically possible to dual partition the SD card, but Windows still struggles if it doesn't recognise the first partition. I still think this approach has mileage (particularly overlaying data on video etc) but given my my goal of this solution to be easily built by anyone, this was getting a little too techie. Besides, I was now learning about Arduino - perhaps I should follow Ian Walkers lead...

As you may have noticed from the picture above, I also discovered a new tool whilst trying to document my wiring: Fritzing - the open source world never ceases to amaze me!

Coming up in Part 2: The Arduino(s)