FreeEMS-Tuner Development Diary - Don't Post!

Aaron Barnes' wxPython based FreeEMS tuning tool. No longer maintained and out of date with the protocol requirements.
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: FreeEMS-Tuner Development Diary - Don't Post!

Post by sry_not4sale »

So, as part of the code sprint - have done heaps since the last update.

For an idea:
http://github.com/srynot4sale/freeems-t ... s/devtrunk

We fixed a bug causing the current operating cell to not highlight correctly. Also some bugs relating to how I used load and rpm values (showing how much of a tuning, and python mathematics n00b I am).

Fred is using the app as we speak to tune his Volvo, with the help of some basic data logs being displayed in the status bar. All the code is pushed to github so feel free to give it a whirl with some of the datalogs Fred has posted and the File comms plugin! :)

Lots of hacks and nasty code, so the next job is to set up some unit testing, and then start refactoring stuff to be tidier and better performing :D

Oh, and if anyone can help me with an algorithm for picking nice colors in a range from red->green->blue(?), that would be great. Red->green was easy, but it doesn't have enough change for small values. I got a yello/red/green/blue working, but it had dark spots and was a bit nasty :(
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: FreeEMS-Tuner Development Diary - Don't Post!

Post by sry_not4sale »

I love technology...

http://morepypy.blogspot.com/2009/11/so ... rking.html

Every month python becomes potentially faster as alternative VMs/compilers become a reality :D I imagine in a year or two python performance in the tuner will be a complete non-issue.
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: FreeEMS-Tuner Development Diary - Don't Post!

Post by sry_not4sale »

Yay! Exciting to see progress on the firmware again!

I've started looking into the comms code for the best way to handle syncronous packets.

I will post my recommendations here soon :)
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: FreeEMS-Tuner Development Diary - Don't Post!

Post by sry_not4sale »

OK, looks like we have decided on a path for keeping the map display reliable:

08:12 <@sry_not4sale> fredcooke: I will add throttling to the map view, as you were
saying most packets get ignored 'cos the previous ones haven't yet
been processed by the firmware
08:13 <@sry_not4sale> the throttling will check for responses within x milliseconds
08:13 <@fredcooke> i see
08:13 <@fredcooke> and if not recieved resend?
08:13 <@fredcooke> the trick should be just to not send anything else for N ms or so
08:13 <@sry_not4sale> nah, ignore. do not update the UI until a response is returned
08:13 <@fredcooke> if you do that, it shouldn't ever miss anything
08:13 <@sry_not4sale> but let a new request go through
08:14 <@fredcooke> what about when someone edits a cell
08:14 <@fredcooke> then what?
08:14 <@fredcooke> would seem wrong to reset it to the previous value
08:14 <@fredcooke> popup saying "resend or reset?" ?
08:14 <@sry_not4sale> could get noisy
08:15 <@sry_not4sale> i was thinking have an indicator to show the cell doesn't match
the firmware, like a diff color background
08:15 <@sry_not4sale> and hide the indicator when i get the response
08:15 <@fredcooke> ok
08:15 <@fredcooke> makes sense
08:15 <@sry_not4sale> but let someone mash the "up" key
08:16 <@sry_not4sale> and it will wait for x ms or a response before sending any new
packets
08:16 <@fredcooke> ok
08:16 <@sry_not4sale> e.g. user presses up -> send packet saying 3 -> up (4) -> up (5)
-> response (or timeout) -> up (6) -> send packet with 6 value
08:17 <@fredcooke> would it be beneficial to seperate the delay and the response
08:17 <@fredcooke> ie
08:17 <@fredcooke> the delay is mandatory anyway
08:17 <@fredcooke> response or not
08:17 <@fredcooke> two seperate things
08:17 <@sry_not4sale> delay is mandatory, unless the response is already received
08:17 <@fredcooke> lockout sending for N time
08:17 <@fredcooke> and expect response or not in Y time
08:17 <@fredcooke> sure, yep
08:17 <@sry_not4sale> sweet
08:17 <@fredcooke> response should end the delay for sure
08:18 <@fredcooke> then we can set the delay on the long side and not lose efficiency
08:18 <@sry_not4sale> yup :)
08:18 <@sry_not4sale> mmm
08:18 <@sry_not4sale> what what color for the UI
08:18 <@sry_not4sale> maybe a pulsing background?
08:18 <@fredcooke> hmm, dunno
08:18 <@sry_not4sale> to say the change in value isn't confirmed
08:18 <@fredcooke> btw
08:18 <@fredcooke> it could be that my shit is buggy in this respect
08:18 <@fredcooke> ie
08:19 <@fredcooke> i might be missing packets when i shouldnt
08:19 <@sry_not4sale> either way
08:19 <@fredcooke> i have no way of testing that yet, though
08:19 <@sry_not4sale> we need to make sure the display is reliable
08:19 <@fredcooke> yes
08:19 <@fredcooke> absolutely
08:19 <@fredcooke> the user shouldn't be mislead
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
Post Reply