We have a new batch of PCBs, issue fixed. The Greenpower teams who ordered the last one have already had the new boards, and we can now send out new kits. To help with the build process I have just posted a video showing how to put together your eChook Nano v1.2 board.

Since the first prototype we’ve answered lots of questions through email and messages, and always wanted these to be more public so they could help others with the same or similar questions – something like a forum! Since the GP forum is unfortunately closing, it seems even more relevant to have somewhere to discuss all thing eChook and help each other out with anything from building the boards to analysing that spreadsheet full of data. So for further discussions, we’ve set up http://echook.boards.net. It’s a little empty right now but I’m sure we can start filling it up.

We will also be writing articles for Greenpowers new ‘How To’ section, both eChook specific, and more general ways of using an arduino with your car, so hopefully the eChook forum won’t detract anything from the greenpower site.

Disappointingly we are having some issues with some of the boards from our first stack of eChook Nano v1.1’s. So far the quality of boards (v1 and other projects I have worked on) from dirtypcbs.com has been great, their cheap and fast service always delivering good quality boards without issue for my needs.

I was initially a little displeased when I received this latest batch, 12 eChook Nano boards, the first kit board we would send out for schools to test. I had hoped the schools would mostly be testing our documentation not our board quality!

The registration of the silk screen is quite poor. This means that the silk (black lettering/numbering) was not nicely centred on around the components. While this is annoying and leads to a less professional looking product I didn’t think of this as a major concern as it would not impact functionality and the board that was put together showed no signs of any issues and passed all of our tests.

Looking in more detail at some of the other boards received (work have recently purchased a microscope for my lab) I noticed that it wasn’t just the silkscreen that wasn’t on centre. The pictures below show the extent of the problem quite well, with the plated pad area (shiny metal) clearly not centred in the area where the solder resist should be removed (the black area). The solder resist on these boards is the white stuff on top, this resists solder and makes a PCB much easier to solder together as it will stop the solder flowing, in our case down the tracks and potentially in to other components. Specifically here, because the board has a large ground plane pour, it will prevent a solder bridge of the PCB pad to the ground plane as the ground plane is hidden below this protective white layer of resist. This is important as (for all track apart from the ground pads), a short to ground will result in either incorrect readings of the sensor data, or worse, a damaged PCB.

Unfortunately…this hasn’t happened in this case. You can see in this lower image the tip of my multimeter probe, just skirting the edge of the solder resist. In this case I am checking around the 12V battery pin. Around the very edge of the white region I was finding my multimeter continuity test was showing this region as connected to ground, not good. This means that the ground plane is slightly showing through the solder resist. If I were to solder this pin it is likely that this would be bridged and cause a short between the 12V input and ground.

Can this all be blamed on the manufacturer of the PCB? Simple answer, no! Although the offset here has resulted in an issue I (as the PCB designer) could have taken steps to reduce the likelihood of this occurring. What I now realised I should have done is reduce the size of the area that is removed for the solder mask, effectively making the solder mask (white stuff) bigger and closer to the plated pad (a smaller black area). Doing this without changing the clearance of the pad area to the ground plan, this would have the effect of covering up a larger amount of the ground plane so even when the registration is poor between these parts of the PCB it is less likely to leave exposed ground plane showing.

An annoying blog post to have to write but a valuable lesson either way and certainly something that has added to my learning of the finer details of PCB design. The team will be modifying the gerbers and getting some new boards in to rectify this issue as soon as possible so we can get the kits out there!

These boards have a different layout, different DC-DC Voltage regulator with short circuit protection and reverse polarity protection, a lower component count and design changes to make them easier to solder. We have also differentiated the power connector to all the rest so that it is far harder to accidentally fry the Arduino! The functionality remains the same as the original prototype boards.

Thank you very much to the teams who gave us feedback on the initial boards 🙂

We are also re-organising and re-writing a lot of the documentation to make it easier to follow. The build instructions for the eChook board are complete, I’m currently writing up the section on connecting the board to the car and instrumenting the car.

We are providing these eChook boards in kit form, for students to build and program. All instructions are provided in the documentation. We’re still selling them for £25 posted for the kit shown below. You will need to purchase the LEM HAIS 50-p current sensor(~£18) separately. This is cost price – we’re not aiming to make a profit.

*Kit Photo missing a diode and length or ribbon cable that are also included.

Alternatively if you are lucky enough to have PCB making facilities, all the files are hosted at https://github.com/eChook and you can make your own 🙂

A fantastic day at Rockingham saw the weChook racing team manage to run an echook nano for 2 hours on our car Electric 2Galoo. Thanks to all who came to speak to us on the day about the car, as always it’s a pleasure to talk to like minded people who just love to build race cars!

We had great success with out 2 hour test using the echook board both as a motor controller driver board as well as a telemetry data logger. The phone screen was used to inform me (the driver) how much current we were drawing and was perfect for testing our race strategy plans. We also managed to collect 2 hours of good data from our sensors, result!

David @cullimoreracing has kindly offered to run an eChook Nano on Jet2 but we will be looking for more test cars to get these boards on to for the start of the season. Before we do do this we need to tidy up our documentation and work out how we are going to fund the project at this point (the boards are cheap but with components the cost is looking to be ~£30 before you add on the £17 current sensor…we aren’t trying to make any money from this project but we are also not trying to lose too much, we have racecars to build!). We have 9 more boards from this initial batch, watch this space for what we plan to do with them….

Having skipped out on the Goodwood Test this year (for a few reasons really – we hadn’t finished making anything yet, and Goodwood is a less important circuit to get right these days due to the relocation of the final), 2016 opened for weChook Racing with the season opener at Rockingham.

For those that don’t know, the Season Opener has traditionally consisted of an extended test session in the morning (over three hours this year) followed by two F24 format races in the afternoon. This means an 80 minute race with 2 mandatory driver changes – a slight problem for us!

We’d been pretty lazy in the off season – 2galoo had been put in storage after the 2015 International Final, and had barely been touched since. We did a few quick checks on Tuesday evening (we pumped up the tyres!) before tossing it on the roof and strapping it down.

We drove to Rockingham on Wednesday morning, and after bumping into everyone’s favourite commentator on the road, we arrived just in time to join the start of the scruiteneering queue. 2galoo flew through the checks – including the new impact foam regulations that had caught out a number of teams at the Goodwood test – and received its MOT sticker, giving us plenty of time to get out on circuit.

We had two major objectives for the test – the first was to try out the eChook Nano (read about it here), the bluetooth data logging and telemetry system that we have co-developed with Driven. Our second objective was to extend our understanding on how to use our gearing to maximise race efficiency.

We hit the circuit early in the session and completed 12 laps. Ian drove the first few laps in ‘constant current’ control mode, using the gearing to keep the current as close as possible to 25 Amps. Afterwards, we switched the strategy to run consecutive laps in each gear. The eChook worked admirably, until the phone used to log the collected data fell off the dash into the depths of the car and dropped its connection.

After completing the first planned stint, Ian bought the car back in for a few checks – we were particularly interested in the motor temperature after running a few laps in high gears with high current consumption. Thankfully, the temperature weren’t too high, although this doesn’t mean it wouldn’t start cooking if we ran a whole race at those speeds!

Having realised we weren’t collecting any data from the first stint, we decided to send the car back out in the last 30 minutes of the session. A quick battery change later, and 2galoo was back out on circuit, fitting in another 10 laps. I’ll be writing a separate blog post on the data we collected later on.

After a quick break, it was time for the first of the season opening races. As alluded – we had didn’t have enough drivers to actually compete in an F24 format event, so we used the race as another test session. We followed a similar pattern as we did in the morning, a few constant current laps followed by a lap in each of the gears. This consumed far more current than we would normally do during a race, so Ian retired the car after about 50 minutes and 16 laps when the voltage got a bit low, in order to protect our best set of batteries. We matched the fastest lap that we achieved during the international final weekend and had got up up to 2nd place at one point.

After the first race we’d done all of the testing we needed to do, and collected a lot of good data, so we elected not to run in the second race. We had a great day overall, the weather was great and 2galoo ran smoothly and reliably – a fitting sign off after what is likely to be the car’s final event.

This feels like a return to normality after the end of the 2015 season – Congratulations to Dave (and the newly extended Cullimore Racing team) for a pair of victories – Jet II really is the real deal and the design work that has gone into it is the inspiration behind what we’re doing with 3galoo.

The newly arrived Bluebird looked highly impressive – I’m sure it will be a threat in whichever class it ends up entering! The rebranded Minion/ Scooby Too looked very impressive, and completed a whole lot of laps in practice. Probation IV showed up with a new and dapper set of orange bodywork, that looked just a bit like a boat.

Thanks to the GP staff for another cracking event! We’re looking forward to the next race, and to joining them at STEMtech in June.

Having covered how Ian uses our measured data whilst out on circuit in the last post (read it here: http://wechook.com/?p=518 ), I’m now going to cover what we can do with it when we’re not racing – be it in the pit lane or once we’re back home.

The first step is getting the information from the car to my laptop. As long as we remember to put it in, the telemetry board will record all measurements to a text file on an SD card, which can then be easily transferred across to a computer. The system also transmits data live wirelessly during a race, but this is of little use when the car goes out of range or behind a tree – pretty much everywhere apart from Merryfield and Dunsfold Park.

For the information to be valuable during the constraints of a race day, all the information has to be pulled together quickly – there’s not a lot of time to make changes in between the end of practice and the start of the race so every second counts. In order to maximise the utility of our data logging, I wrote some code in MATLAB that will read the data files, and generate a report with useful plots and calculations. I’ve uploaded two of these reports, from two different races at Rockingham to the website:

As an aside – I heartily recommend that any aspiring young engineer go out there and get some experience using MATLAB – it is easy to pick up and there is a huge wealth of help and support available online. As a data analysis and visualisation tool it far exceeds Excel, and will make a piece of work look far more professional! I use it extensively at work to perform simulations, automatically generate reports (automating a task that used to take hours keeps my manager very happy) and design control algorithms. From experience, I can also say that if I’d learnt to use it whilst at university, it would have made my dissertation project a whole lot more manageable, due to the Gigabytes of data that I was dealing with from incredibly high resolution measurements of impact data.

Sales pitch over! Once I’ve worked my magic with MATLAB and generated a report we can work out how much current and power we were using at any given point, and how fast we were running the motor. Using this approach with data from a run in practice, we can determine whether we can complete a full race distance at that pace without flattening our batteries (I’ve done plenty of battery testing, so I have a good understanding of how much energy the batteries have available).

Based on the data from the Rockingham heat, we were able to plan our power usage for the Lap Race – we estimated how much shorter it would be than the standard hour and then determined how much more quickly we could discharge the battery. If you look at the two reports linked above, you can see that we drew just under 25Ah from the batteries in both events, but at a higher average rate in the lap race.

Also shown in the reports are traces of throttle position and motor speed. Comparing the throttle trace from the Lap Race to that from the heat earlier in the year, it can be seen that Ian is performing fewer gear changes, and spending less time at part throttle. It can also be seen that motor speed tailed off much more quickly at the end of the Lap Race – we’re putting this down to the fact that we were using our best batteries in the Rockingham heat, but we saved them for the F24+ decider on the International Final weekend.

We’re planning to extend our data collection next year to include wheel RPM (from which we can calculate vehicle speed, and determine which gear we were in) as well as motor temperature, to avoid the risk of cooking another one! With this data we plan to be able to run an improved race strategy in the 2016 season – instead of targeting a constant rate of discharge from the batteries, we will be looking at how we can most effectively convert each unit of energy into speed.

Seeing as we’ve been espousing the virtues of data collection of late, I’ve decided I’d best write at least a bit about some of the things we do with our data.

I’m going to split this into two posts – the first covering how the driver uses the information during the race, and the second discussing what we do with the logged data in between sessions and race days, as well as what we’re hoping to achieve in the future.

From the Rockingham heat onwards, our cars were fitted with a screen that showed the driver a live readout of battery voltage, motor current and motor speed. Voltage isn’t much use on a moment to moment basis – it fluctuates with the current that is being drawn, meaning there’s no simple way to estimate the charge left in the battery

Motor RPM is also tricky to use – we know we need to keep the motor in its ‘happy range’ in order to keep power consumption low and stop the temperature from getting too high, but it’s difficult to plan a race using motor speed – without a good model of the motor, we don’t really know whether we need to hit 1750 rpm or 1800 rpm to make it to the end of the race!

That leaves battery current as the most useful resource to the driver. We’ve done plenty of testing, which shows that our best batteries have a capacity of roughly 25 Amp-hours, when discharged at a high current. For comparison, our worst batteries have a capacity of 22Ah, which can make a big difference when trying to reach the end of a race.

With 25Ah at our disposal, and an hours worth of racing to complete, the maths isn’t too hard; we need to hit an average of 25A over the course of the race to make sure we get to the end – simples!

With a single speed, relay controlled car, this is achieved through selecting the right gear ratio – get it wrong and you won’t reach the end of the race, or you will get there but at a slow pace. Choosing that gear ratio can be tricky – for me it came down to experience and voltage measurements. I’ll discuss more on this in the next post though!

Electric 2galoo had the luxury of a wide range of gear ratios, and a speed controller. By shifting up and down the gears and by varying the throttle input, Ian was able to target a constant rate of power consumption. At the International Final, this allowed us to control the rate that the battery went flat very nicely – gaining us a place on the last lap as the competition ran out of juice!

The weChook Racing and Driven teams have recently launched a joint project (Project eChook Nano) to develop a standalone system capable of logging important telemetry data from a Greenpower car. Both of our teams feel like we learn a lot from our current telemetry setups and that making this type of information more easily available for other team’s vehicles would be incredibly beneficial and would really help with the engineering and learning aspects of Greenpower racing.

Our aim in developing this hardware is create something simple and affordable that will allow those teams without electronics experience to collect live data from their car for analysis during races, and as something to study in between events. It will be based around an ArduinoNano, and be provided with the base software to perform standard logging functions, whilst giving the students the opportunity to implement their own code to customise the functionality as they see fit.

The hardware is designed to interface with an android app that Rowan has posted about on the greenpower forum here: http://www.greenpower.co.uk/forum/discussion/3335/data-logging-and-driver-information-display-android-app-offer. The hardware on the car communicates with the app via bluetooth, and can provide instantaneous readouts to the driver, as well as logging the information for later analysis. The app will also use the phone’s sensors to supplement the information gathered from the hardware.

A further aim of the project is to provide the ability to live stream the information to web interface via the phone’s 3g connection, allowing information to be viewed live from the pit wall. An exciting prospect to try to understand why a competitor car is accelerating past yours but consuming less amps….perhaps time to get the chain oil out during that next pit stop 😉

We’re designing with the following I/O (and some of our suggestions on what they can be used for):

Our primary intention is for this to be a passive component, that can be added to a car with minimal disruption, and will not affect the actual running of the car – we don’t want to be responsible for taking someone out of a race! The pins are there however to receive a throttle position input, and output a PWM signal to a motor controller. Teams can pick and choose what sensors they feel are necessary for their learning, though we would suggest current consumption is the most interesting!

We’re are currently working hard to get the base system cost less than £40 to make this accessible to as many teams as possible. Sensors are not included in this figure but most are cheap components (bar the LEM current sensor which can be found for ~£18). Due to the open source nature of this project we aim to provide teams with all the information required to source and put together the hardware themselves, but initially we will provide a ‘build kit’ so we can get some hardware out there in the field and get keen teams testing it as soon as possible.

At the very least, we’ll be running the system on Electric TubeOfGlue (the weChook racing team’s development vehicle) for the season if no other teams are interested!

Please get in touch with us on the greenpower forum (http://www.greenpower.co.uk/forum/discussion/3398/introducing-project-echook-nano#latest) or on Twitter (@Ramjet_gpt) if this is something your team would be interested in having or even being involved with. We have captured our ideas here but it would be great to hear from others on what is most important to their team.