Marcos' development comments!

Marcos Chaparro's GPL C++/QT tuning application, now supports FreeEMS too!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

nitrousnrg wrote:
With regards inj time and PW, consider dead time, and multiple shots per cycle. You want to display something like "total fuel delivery time" which I provide as a value in the log, I think. And also actual PW which includes dead time, and combined with number of shots per cycle, and time per cycle, gives duty cycle %.
Yep, my Inj Time (now PW) is the total fuel delivery time, and my duty % is what you said. If you think it could have a better name, tell me and I'll change it. You shouldn't leave the naming in hands of a inexperienced latin american :P
ROFL :-)

Total Fuel Delivery Time
Electrical Pulse Width
Electrical Duty Cycle and/or Fuel Duty Cycle - these numbers will always be different.
What you probably want to stat are :

Good packets
Bad checksums
Length mismatch
Partial packets
Bad data between packets
Escaped byte invalid
Good good! Those are much better than mine.
The trick is that the name matches what the code does! (obviously).

Partial packet = found start, found another start later.
Bad data between packets = any bytes found before a start byte.
Escaped byte invalid = escape byte found, and following byte isn't an escaped escapable byte.

The others are obvious.
I find extra stop bytes because of the way I search the stream, starting backwards from the first stop byte occurrence (instead of searching forwards from the first start occurrence, as you do).

Marcos, if you start backwards from the first stop, you'll never see another stop, by definition. The only cases there are :

* find no start before stop
* find a start at the end of the buffer
* find a start before the end of the buffer

The first means absolutely nothing (partial packet when connecting or stray data in between that happened to include a stop. The second should be the normal case where you find a packet and only a packet. The third just means that you found some stray data before the first packet when connecting, or between two packets if mid stream.

Theoretically I can't see a problem with what you are doing, except that to handle it properly, you need an arbitrarily large sized buffer! IE, if you're getting garbage and looking for a stop, you may never see a stop, and you need to save all data until you can retraverse back through it to find the start. If you look for a start, dump everything before a start, and buffer from start until stop, the hand off to another stage of processing and repeat, that seems to work more cleanly.

Can you explain why you're doing it the way you are and what benefits that has?
Don't mind me, any data between packets is bad, no matter if it is a random byte, or a start/stop one.
That is true, however under some circumstances it should be categorised differently.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Total Fuel Delivery Time
Electrical Pulse Width
Electrical Duty Cycle and/or Fuel Duty Cycle - these numbers will always be different.
I prefer elctrical PW & duty, but I'll put everything in the UI, he who wants fuel duty cycle instead of eletrcial duty cyle can customize the main window.
Theoretically I can't see a problem with what you are doing, except that to handle it properly, you need an arbitrarily large sized buffer! IE, if you're getting garbage and looking for a stop, you may never see a stop, and you need to save all data until you can retraverse back through it to find the start. If you look for a start, dump everything before a start, and buffer from start until stop, the hand off to another stage of processing and repeat, that seems to work more cleanly.
I've been thinking about this, and there isn't a strong reason for doing it that way. Searching for stop bytes allows me to inmediately pass and remove the packet (or corrupted packet, if there isn't a start byte) from the buffer. Once removed, I keep searching for another stop, if it doesn't appear, I do nothing; just wait for the next serial->read() to append data to the buffer.;

I can change it, shouldn't be more than 3 or 4 lines of code. The results will be the same, but if it improves the readabilty it worths the effort. I can have a buffer overflow in case there is a large stream followed by a random stop byte, but so do you if you have a random start byte followed by a large stream. We both have to look if there is a bigger than 2 MAX_PACKET_SIZE (or whatever you call it, i'm not in my pc:-( ) stream in the buffer. Anything bigger that don't seems like a packet must be removed.

I'm going to code imaginarily... see you guys.
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

I stand corrected by an inexperienced latin american ;-) You're right. No difference, perhaps with the exception of naming of dud data? But that is irrelevant, really. In any case, don't change it, give me some variety to work against :-) I like it.

With regards, duty/pw etc :
  • I want to know the electrical PW to ensure it makes sense for the settings. (2 shots = half of fuel delivered + dead time for example)
  • I want to know the fuel delivered to ensure it makes sense for the injector size, cyl size and operating conditions.
  • I want to know the electrical duty to see if we're close to maxing out the injectors.
  • I want to know the dead time to ensure it makes sense for the battery voltage observed.
Feel free to correct me on this again if it doesn't make sense to you :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Alright, agreed :-)
I'm going away, 'till friday or so (I have an exam this thuesday) . After that, I'm back to this.
My TODOs are the communications and GUI improvements.
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

Have a good trip! :-) Hasta luego!
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Well, the function that has been working for years, suddenly doesn't work anymore.

Trying to connect the device (ie, opening the serial port) ends in a quite remarkable hang.
Everything stops here:

Code: Select all

Posix_File->open(QIODevice::ReadWrite|QIODevice::Unbuffered)
I tried it in two Debian PCs, with several releases of ecumanager...

That was my wtf moment of the weekend.
Marcos
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Apparently, the serial port library has become obsolete.

Using the latest version of QExtSerialPort, the communications works fine (uses qexterialport as a shared library).
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

Is this the copy/paste code that you have included in the project? There must be a way to not have to do that, surely? just use the headers and the library, and not build it all yourself? Explain why you have it as you do, and why it is necessary.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Mmm, good point. Now qextserialport can be removed (that code isn't used at all!). I'll make a deb package for it, and other for ecumanager. That will take some time.

Let me try to use qwtplot3d from the debian repository, there should be a way to use them as a shared library instead of built in code.
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

Sure, even that is better than building it every time. But I would have thought it was already out there as a lib that you could install? If not, I'd be surprised if something similar wasn't. Or is serial too obscure these days?
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply