Project Logs

Collapse

• Project is not over

  Jussi Luopajärvi • 10/22/2020 at 11:19 • 0 comments

  Long time without any updates and with same reason as before, just too lazy and busy to write updates. All the time have been used to for developing the system. Maybe the biggest news is that the project has become a bit more serious and target is to make a commercially available product. Best place to follow up the project TestLogger Facebook and Instagram pages.

  Basically every single aspect of the project has progressed a lot since last update. HW is redesigned, configuration application is redesigned and most importantly there is our own analysing application available!

  I have also designed a custom binary format for the analysing application and that will be open source. About that I will make a post soonish...

• Big progress on the background

  Jussi Luopajärvi • 02/07/2020 at 06:51 • 1 comment

  Finally I got my act together and write some update about the project. Even though I haven't written any updates, the project has progressed quite much, so here is an overview of the all the components.
  

  Software

  The software for desktop has been completely done from scratch to have more functionality, better user experience and to work cross platform. Previously the desktop app was just simple CLI app for Windows.

  Because web technologies are close to my heart and from those I have the best understanding (still not good I would say), I decided to give a try for Electron to create the desktop application as it's Node.js based (First time using Node.js) and allows compiling for Mac, Windows and Linux from the same source code. This is a big benefit for me as I'm doing everything by myself.

  So far I've had good experience with Electron and only downside has been the large application size (over 100MB). See https://www.electronjs.org for more info. If you quickly need to make simple desktop app, I definitely recommend to have a look. I'm not sure if it is enough for applications where high performance is needed, but looks really good for my use case.

  So I made app called Connector which has two main features. First one is the data import from memory card and converting it to Motec i2 or CSV file format. Second feature is the configuration of logger. In the configuration section you can generate the config file via UA but you can also calibrate the device. In other words you connect the device via USB and it sends the current measurement values to the configuration application where you can use the numbers for calibration purposes.

  Here is a video how it works.

  Analysing too for the data is the tricky part. As mentioned I'm using Motec i2 which I think is a brilliant piece of SW, but no one else can use the file converter except myself. I have now contacted multiple tool vendors and asked if they have any interest to start co-operation with my project. Let's see if that brings any results.

  Mean time I've been preparing for the worst which means I need to develop my own analysing tool. Probably I will create some simple prototype with Electron, Vue-grid-layout (see https://github.com/jbaysolutions/vue-grid-layout) and LightningChart (see https://www.arction.com/lightningchart-js/) to see if I could create my own analysing tool. But this is just an idea in my brains for the moment to get something done quickly and probably proper developers would kill me for this idea. Benefit of this would be to have both desktop and web interface for the analysing tool. Of course the possibility to use data either from remote DB or locally generated files. One thing I would like to achieve is easy sharing of data.

  Read more »

• IR Beacon and laptimes

  Jussi Luopajärvi • 05/05/2019 at 19:50 • 0 comments

  Laptimes is a key element when analysing performance and in this case these are generated with a help of IR beacon(s). Generating laptimes can be achieved with one beacon and by adding one or more beacons it’s possible to generate split times.

  Beacon sends 38 kHz infrared signal on selected pulse length which is then received in the car and logger triggers the lap indicator. Beacon has a switch where the 38kHz pulse length can be changed and this is used to identify if beacon signal is main laptime or split time.

  Beacon also has a lithium based battery which has 2000mAh capacity and nicely fits behind the PCB. To control the battery, there is also battery charging circuit where charging done via micro USB. Battery level indicator is built with four input comparator and bi-colour leds.

  Read more »

• What the data shows?

  Jussi Luopajärvi • 01/28/2019 at 14:19 • 0 comments

  It's been a while since last post and things have progressed a fair bit on HW side like Collector Full V2.2 and completely new IR beacon, but that's not the topic for today. Finally I'm posting about something else than HW development and it's about the collected data.

  I've been using the Full V2.1 with my 2WD buggy (It's Team Associated B6.1D, see https://www.teamassociated.com/cars_and_trucks/RC10B6.1D/Team/) and I've logged the channels as follows.
  

  • Steering
  • Throttle/Brake
  • RPM/speed from motor sensor port
  • Wheel speed from both rear axle outdrives
  • Battery voltage from two cells
  • G forces on three axis
  • Angular velocity with gyro
  • Damper movement on rear corners
  • Laptimes

  Of course this amount of channels gives you a massive possibilities to analyze both car and driver, but here few simple examples to start with where you need only steering, throttle, speed and vertical acceleration.

  Read more »

• Remember the f*ing review

  Jussi Luopajärvi • 01/12/2019 at 07:22 • 0 comments

  I designed the V2 for Full version in a bit of rush and guess what, it was a massive failure. The boards were working nicely, but microSD slot was placed 180 degrees in a wrong direction (slot was facing against USB connector...), analog 3V3 was not connected to upper board due to an issue in schema plus few other minor issues. 

  What did I learn from this? REVIEW YOUR SCHEMA AND BOARD DESIGN BEFORE SENDING IT TO PCB MANUFACTURER!
  

  One positive learning from this episode was the possibility to move SD card slot outside the device. Usually the logger needs to be installed on very tight place, so sometimes it's actually good to have an option that you can bring the SD card slot to more accessible location.

• Firmware architecture depression?

  Jussi Luopajärvi • 01/01/2019 at 10:55 • 0 comments

  First of all Happy New Year everyone!

  Last couple of weeks I've been starting to do a spec for the firmware as the hardware starts to be good enough that I can live with the limitation. The firmware design just feels overwhelming task and even difficult to decide where to start. I've never done a spec for embedded SW and last time I've been doing UML charts was probably around 10 to 15 years ago. I already know quite technical challenges I need to resolve, but before I go that far I need to find a how present the firmware on paper. I bought this book to get some guidance https://www.amazon.com/Real-Time-Embedded-Systems-Principles-Engineering/dp/0128015071

  Next step is to learn some good practices what to follow when doing design decisions which is also a challenge as my experience in programming is quite limited. Especially with C.

  Last big step is to actually actually resolve the technical challenges and writing the code. For example how to get each channel to log data on correct logging rate. How handle the buffer. In which format the data should be written because data is coming to buffer on different rates.

  Do you have any suggestions how to start designing FW architecture based on RTOS? If you have good articles to read and learn, please share. This is probably going to be a long project and just need to take the needed time to do it one step at a time and avoid doing shortcuts.

  Read more »

• Failed full version

  Jussi Luopajärvi • 12/17/2018 at 21:35 • 0 comments

  A bit of brake from updating as I have had some work and holiday trips. After the first version made completely by myself which had fairly limited amount of inputs, I decided to go for the full version with my own design. 

  Base guideline for the design was same inputs as I had for PYB shield with much smaller area covered. Usually the height isn't a problem but area used is a big issue. I decided to to with 2 PCBs stacked and connected to together with three board-to-board connectors.

  The goals were achieved with a big but. It was almost half of the size compared to PYB shield version and it had the same connectors. Also the weight was surprisingly low as you can see from the picture below. It was almost 10 grams lighter than PYB shield version. The problem was related to connecting the two PCBs together and using the device on car which jumps and get's massive hits. The boards were not sticking together and then everything fails. 

  Read more »

• First version without Python board

  Jussi Luopajärvi • 10/20/2018 at 15:50 • 0 comments

  A time for another update as I received the first PCBs for a basic logger version which is completely own design and doesn't need a python board as a base. My friend drives a 1/12th pan car which really small and there is no extra space available, so python board shield version is a no go. I thought that maybe that is a good place to design completely own version of the logger. My friend gave a space constraint for the device that it shouldn't be bigger than Sanwa rx-451 receiver. I got quite close to that requirement maybe small fine tuning gets me to that target. Currently the board size is 33x22mm, so it's no too bad. Functionality is pretty limited though..

  The board can log steering, throttle, laptrigger, speed/rpm from motor sensor port, g-forces and gyro values. This is good enough for me to verify the base design for the board and for 1/12th pan car that information already gives enough input to analyze and basic behaviour of the car.

  I don't have any data yet to look, but the reduced size makes the installation so much easier. Also the weight is over 10 grams lighter compared to the last Pyb shield and Python board combo. 

  Read more »

• PYB shield V2

  Jussi Luopajärvi • 10/08/2018 at 13:48 • 3 comments

  In the previous post I mentioned about new prototype and it arrived as planned during last week. I called this as Python board shield V2. As a summary main changes were as follows.

  • Move from through hole components to surface mount components
  • Move from 0.1" header connectors to JST-SH connectors
  • Take RPM and temperature information from motor sensor port
  • Changed the shield from bottom side of PYboard to top side and solder it to PYboard.

  So basically everything was new. 

  Build went pretty smooth even it was one my first times soldering SMT components. My loyal Weller WTCP 51 with 0.4mm tip did the work nicely :) As a result I got a prototype which was 4 grams lighter and few milli meters lower. Pictures shows a bit more

  Read more »

• Yet another shield for Python board

  Jussi Luopajärvi • 10/03/2018 at 11:46 • 0 comments

  This week I should receive a new shield PCB for the collector. I think this shield is already 5th or 6th version, so there has been quite many iterations. This one is a bigger change as this is the first version with surface mount components and sensor connectors are changed from 0,254" header pins to JST SH connectors. There is two reasons why I wanted to change the connectors. First one is surface mounting and smaller size. Second reason is probably the bigger one. With JST connector you can make sure that the connector is always plugged in the correct way.

  Hopefully this helps me to reduce the height and weight of the package. It's still not going to be what is my target but at least one step closer. Also hoping that I get to test this one during the next weekend. I will definitely post some pictures if that happens.

  The next step will be a version without Python board, so get everything on one board... 

View all 10 project logs