Hi,
I decided it was time to learn some electronics, so am busy developing a data logger ( 8 analogue channels, 2 digital, Gyro/Accel ) with Bluetooth support for both master and slave radios (idea being to act as a proxy for external bluetooth GPS and present data to race chrono as a normal slave device) and was planning to send in RC$ sequences that are used for other data loggers.
I plan to open source both the hardware and firmware once debugged for anybody who wants to play/build one. (PCB Boards being produced in China as I write this)
I see in RaceChrono Android versions that there are specific device types for data collection. Each one appears to relate to a specific pre-approved premium device, so assume that combinations of RC$ strings and GPS data is dependent upon the devices selected, but am not sure?
Can you confirm if it is possible to send in full GPS sequences blended with RC$ sequences from the same device and/or if you have any docs about the integration options already available ?
The device will/can be used as a standalone data logger to SD card as well should it not be an option to interface with Race Chrono, although RC was the original goal when designing it as I am already a user/fan.
I welcome your feedback / comments.
Simon (aka enly1)
Comments
https://www.sparkfun.com/products/11058, 20hz would be pretty awesome as that rivals some of the best commercial offerings.
also, how fast would your analogue channels be? I think for data such as RPM you want as much as you can get, preferably more than 50hz for better data analysis.
Currently RaceChrono for Android doesn't support $RC sentences blended with GPS sentences. It is not a big problem to fix this support. Only my requirement is that the $RC sentences have calculated timestamps. I would also eliminate the second Bluetooth connection and add some integrated GPS/GLONASS board via serial connection. Bluetooth is a bitch to work with, it could be the achilles heel of your product...
-Antti
I did think about embedding a GPS, but already had an external GPS unit and the master bluetooth was simple enough to integrate.
Already have the mock up on dev board connecting out to an external 10Hz bluetooth GPS and pulling the strings. Was going to use the GPS as the sync event for data capture collection point, so timing references would not be an issue.
How well it will work in practice I don't know, but I did add an expansion header that has serial RX/TX/3.3V/GND on it, so can easily drop in a GPS daughterboard / expansion module with only 4 lines needing to be connected and a simple firmware expansion or simply botch/patch one into the existing bluetooth board footprint as its a serial interface there also.
I'm using an STM32F103RBT6 so have 72Mhz of CPU processing time to play with, controlled with a Chibios/RT based firmware.
The OPAMPs I have fronting the ADC are good to 1Mhz+ from memory and the 12Bit ADCs should do a decent job of capturing as often as I need.
ADC conversion time:
– STM32F103xx performance line devices: 1 μs at 56 MHz (1.17 μs at 72 MHz)
As for the question about overall speed - hardware is pretty neat, so we'll see what we end up with update rate wise, although I don't personally expect to be running over 10Hz for my activities. I only do track days, so its just for fun and really only to meet a simple need I had of understanding when traction control kicked in and what I was doing at the time - but got carried away :-)
Or - it could all go pear shaped and nothing work - as I indicated, i've never done any electronics hardware before...
So will solder up the board and start on the core of the firmware when the PCB arrives from China in the next few weeks on the assumption that if I have a working model that you can accommodate the GPS+RC from a single device.
https://www.sparkfun.com/products/11058 - the price is the reason i've not opted for that.
Most people who use RaceChrono already have a decent Bluetooth GPS and the radio interface works out to be about £4 for the bluetooth adapter. Although as mentioned above, it would be easy to integrate one on the existing board setup via Serial or I2C (both available on the expansion port)
http://www.techlib.co.uk/race/raceos.png
Two major benefits of integrating a GPS board would be external antenna connection and saving to sdcard before Bluetooth connection. On many race cars the GPS reception is a problem, but the cheap receivers do not offer external antenna connector. You can take the receiver outside but it will eventually fail from moisture. Also your data will be always safe when it's saved to sdcard. If your Bluetooth fails then you can always pick it up from the card.
Also not sure how the save to SD card comes into play - I can do that at any point, although was just planning to use GPS updates to keep everything in sync. The unit has a real time clock on it, so can just data log to SD without bluetooth if I wanted as well on a timer. Its all down to the firmware I work out...
In relation to the external antenna, I understand where you're coming from - didn't really think about cars and reception as I built it with motorcycle use in mind. The bluetooth modules do have a connector point for an external antenna mount, but i've not made use of them - maybe something to think about on rev 2 of the PCB as there is no way I got everything right first time out.
My concern about SD card was not that much to do with timing, it was only about risk of losing data, if not all devices are "wired" to the recording device. After data is saved to SD, it's safe to have wireless, as the data can be collected from the card if needed.
Also not sure if external Bluetooth antenna would be required, but rather a GPS that would have connection for external GPS antenna. The normal consumer GPS all have integrated GPS antenna and no connector for external. VBOX Sport is one of the few to actually provide this. That sparkfun board has a connector so therefore would be interesting to see how good it is with proper roof mounted antenna.
Yes the price for those dev boards are pretty insane, unfortunately outside of sparkfun i am not aware of anyone making a breakout board with the gps chip pre-populated, those BGA are basically as diy unfriendly as it gets.
another advantage of having integrated gps would be one less thing to have to power\remember to charge. Currently I have to charge my phone, my gopro, and my external gps. One less thing to worry about is always good
Its been a while since this posting but while progress is slow due to available time (and skill), the hardware is more or less all up and running and the firmware is well underway.
I tested RC last night against my device while proxying through all the GPS data which seemed to work perfectly.
So I'm kind of at the point where I need a release of RC that allows RC strings and GPS strings to be blended in the same bluetooth connection.
You indicated that it wouldn't be too much of a problem enabling the combined feed - any chance you could send over a dev build with that capability enabled ( and pref a build that won't timeout on trial etc )
I was reading a post about the $RC and $RC2 strings and only just realised that Gyro support has been dropped, which is a real shame as it was one of the main reasons for me doing this - wanted bike lean angle to be blended with throttle and traction control indicator data so I could work out riding style stuff etc, so will have to loose one of the analogue channels and send the data there instead.
Thanks in advance
Simon
The gyro support would be really good if we can make use of the knowledge that its gyro data - in my case, I'm only interested in bank angle on the bike to know actual lean angle, but have all data available for anyone that wants to use it.
Anyway, No issues streaming back $GPS strings and $RC2 channels with timestamps - firmware is being developed, so I can do it however you want.
I expect to be streaming through (bidirectionally) GPS input/output ) between your app and the GPS unit to allow to MTK specific handling etc and will so you will be getting that output untouched from the GPS unit at the other end of the bluetooth proxy. You will also be getting my $RC2 strings injected with the local realtime clock timestamp (which will auto-sync with GPS).
So if you let me know the format you want to work with, I can send back a sample of the blended data. I expect to have the option of multiple $RC2's per round of GPS strings - i.e. Different data rates.
Let me know how you want to play it.
PS - looks like i'm not the only one either, so if we could provide a summary of the current RC2 format and the constraints we need to work within it would probably be good.
Thanks again
I understand the need for gyro, but let's create the blended support first. The $RC2 sentences are completely unsyncronized to the $GP* sentences, so you can output as many as you like, and when ever you want.
The up-to-date $RC2 format is described here: http://www.racechrono.com/forum/#/discussion/comment/4330
The link I was using, so on the same page in terms of structure.
So how do you want to do this - do you want me to send over a sample output ? It will just be GPS output + the RC strings though obviously or you able to distribute a dev version with the ability to consume both and I can run a simulation and send the expert log capture ?
I was pondering creating the drive around sample you expected but also then creating a custom version with blended data from a control set that covers all data entry ranges that the RC2 spec had,so it can effectively be unit tested from your perspective.
Given the simplicity of creating the RC2 strings at my end, I'm not expecting any issues - but maybe that's just optimistic.
With a quick walk about test though RaceChrono seemed to like the data stream (largely ignoring the $RC2 strings it was also receiving), so looks good so far :-)
$GPGSA,A,3,11,32,01,19,27,22,28,14,03,,,,2.57,1.09,2.33*09
$RC2,202352.781,1591,,,,1.590,3.181,101.591,201.591,301.591,401.591,-101.591,-201.591,-301.591,-401.591*11
$GPGSV,3,1,12,11,74,267,40,19,56,146,38,01,51,269,43,32,48,188,42*7A
$GPGSV,3,2,12,03,40,159,27,28,33,302,30,22,31,057,42,14,28,085,33*78
$GPGSV,3,3,12,33,27,195,30,27,24,142,31,20,14,216,,24,02,020,32*72
$GPRMC,202352.800,A,5323.2068,N,00238.9451,W,0.01,18.93,070714,,,A*4C
$GPVTG,18.93,T,,M,0.01,N,0.01,K,A*0E
$GPGGA,202353.000,5323.2068,N,00238.9451,W,1,9,1.09,32.0,M,49.0,M,,*7D
$GPGLL,5323.2068,N,00238.9451,W,202353.000,A,A*45
$GPGSA,A,3,11,32,01,19,27,22,28,14,03,,,,2.57,1.09,2.33*09
$RC2,202352.981,1592,,,,1.592,3.184,101.592,201.591,301.592,401.592,-101.592,-201.591,-301.592,-401.592*1B
$GPGSV,3,1,12,11,74,267,40,19,56,146,38,01,51,269,43,32,48,188,42*7A
$GPGSV,3,2,12,03,40,159,27,28,33,302,30,22,31,057,42,14,28,085,33*78
$GPGSV,3,3,12,33,27,195,30,27,24,142,31,20,14,216,,24,02,020,32*72
$GPRMC,202353.000,A,5323.2068,N,00238.9451,W,0.00,18.93,070714,,,A*44
$GPGGA,202353.200,5323.2068,N,00238.9451,W,1,9,1.09,32.0,M,49.0,M,,*7F
$GPGLL,5323.2068,N,00238.9451,W,202353.200,A,A*47
$GPGSA,A,3,11,32,01,19,27,22,28,14,03,,,,2.57,1.09,2.33*09
$RC2,202353.181,1593,,,,1.593,3.186,101.593,201.593,301.592,401.592,-101.593,-201.593,-301.592,-401.592*10
$GPGSV,3,1,12,11,74,267,40,19,56,146,38,01,51,269,43,32,48,188,42*7A
I aim to have a drive around at the weekend to get some valid GPS data (moving) and send over a more detailed sample block as requested. Analogue and Digital sample data are linear data points growing at similar rates with either positive or negative inversion and scaling based on the channel - so you will get nice pretty line sequences for the graphs and it should be obvious if they are not processing correctly.
PS - current RC2 Sequence tweaked to look like this ... -
$RC2,203949.368,0,,,,0.123,0.247,100.123,200.123,300.123,400.123,-100.123,-200.123,-300.123,-400.123*28
$RC2,203949.568,1,,,,1.123,2.247,101.123,201.123,301.123,401.123,-101.123,-201.123,-301.123,-401.123*2C
$RC2,203949.768,2,,,,2.123,4.247,102.123,202.123,302.123,402.123,-102.123,-202.123,-302.123,-402.123*28
$RC2,203949.968,3,,,,3.123,6.247,103.123,203.123,303.123,403.123,-103.123,-203.123,-303.123,-403.123*24
$RC2,203950.168,4,,,,4.123,8.247,104.123,204.123,304.123,404.123,-104.123,-204.123,-304.123,-404.123*2A
$RC2,203950.368,5,,,,5.123,10.247,105.123,205.123,305.123,405.123,-105.123,-205.123,-305.123,-405.123*11
$RC2,203950.568,6,,,,6.123,12.247,106.123,206.123,306.123,406.123,-106.123,-206.123,-306.123,-406.123*15
$RC2,203950.768,7,,,,7.123,14.247,107.123,207.123,307.123,407.123,-107.123,-207.123,-307.123,-407.123*11
$RC2,203950.968,8,,,,8.123,16.247,108.123,208.123,308.123,408.123,-108.123,-208.123,-308.123,-408.123*1D
$RC2,203951.168,9,,,,9.123,18.247,109.123,209.123,309.123,409.123,-109.123,-209.123,-309.123,-409.123*1A
$RC2,203951.368,10,,,,10.123,20.247,110.123,210.123,310.123,410.123,-110.123,-210.123,-310.123,-410.123*13
So - where would you like me to send it ?