Bench Test Decoder

For discussing and developing different RPM/Position decoders using our superior modular architecture! One thread per pattern, please.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Bench Test Decoder

Post by Fred »

There is some more general discussion on the topic of bench testing functionality here:

viewtopic.php?f=8&t=1022

This thread is for the decoder aspect and development of it.

Right now there is only a skeleton in place, however that will change shortly, now that I can load s19s from the mac reliably/at all.

The first task is to make it fire internally in a fixed pattern for N cycles and fire off a total pulse of M milliseconds on P channels.

Once that is complete, I will post again and specify the next step.

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
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

I'm revising that "first cut" plan to something a little more sophisticated, but not much.

Conditions of entry:
  • Must be running the BenchTest decoder, error if not. (check decoder name)
  • Must not already be running, error if it is. (run a full extra cycle after last firing to ensure all pulses have ended before clearing flag.)
The output decoder will be told to fire like this:
  • M revolutions (0 - 65535) (must not be zero, error if zero)
  • N events per revolution (0 - 255) (must not be zero, error if zero)
  • O ticks per event (0 - 65535) (must be more than minimum code allowance too, error if not)
And the output events will have the following info provided by a packet:
  • P ticks duration per output event, where P must be less than or equal to a full revolution where a full revolution = O * N (0 - 65535)
  • Q event number to fire from per output event where Q must be less than the number of events per revolution (N) (0 - 255)
This is all pretty simple to implement, and gives a lot of power to the person sending the packet. It will make a good start, for sure. I'll pre-can a few packets of various forms for testing and general use. Then maybe Dave can implement a test tab in mtx which will allow direct control of these options.

Initial packet structure will probably look like this, in bytes:

Header, 1(Mode),1(N events per rev),2(M revolutions), 2(O ticks per event), 6*1(Q event number), 6*2(P pulse widths), Checksum - total length = 24

I'll update once I know more.

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
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

Today I did my first two commits/pushes to the firmware project in a month, and it was this. Hooray. About time! :-)

The documentation currently consists of the following:
The much anticipated Bench Test decoder is now at your service. With a packet length of just 24 bytes (plus headers and footers) it's pint size, but packing a mean punch. The first byte is the mode, currently modes other than "1" generate an error. The second byte is the number of input events per cycle to perform, the acceptable range is 1 - 255, zero generates an error. The third and fourth bytes are an unsigned short which are the number of cycles to execute, 1 - 65535 are acceptable values, zero returns an error. The fith and sixth bytes are another unsigned short which, for now, is the number of 0.8us ticks per event within a cycle, this must be greater than decoder code time (current 666 ticks). The next 6 bytes are the simulated input event to fire on, values greater than the number of input events per cycle are considered off, order is PT2 to PT7. The last 12 bytes are interpretted as 6 unsigned shorts, applied to pins in the same order as the last array. The following conditions apply: 0 = channel off, 1 = PW from RefPW, 2 = PW from Dwell, other values less than output ISR code run time (currently 100) return an error, values over that are used as-is. Lastly, if no channels are configured at all, an error will be returned, letting you know that you're a dumb arse. Enjoy! :-)
And the single test packet which pokes and prods as many aspects as possible, and will be supplemented with actually useful tests later consists of:

Code: Select all

AA 00 88 88 01 14 00 10 FF FF 00 00 00 00 00 00 01 00 00 01 00 02 FF FF 00 00 00 00 ?? CC
Which breaks down into the following:

Code: Select all

0xAA start
0x00 flags
0x8888 payload ID // was 0x7777, but this was invalid
0x01 mode
0x14 events per cycle
0x0010 cycles
0xFFFF ticks per event
00 00 00 00 00 00 - fire simultaneously on the zeroth event of each cycle
0x0100 a very short pulse of 256 0.8us ticks (visible on an smd led in daylight)
0x0001 use refpw for pulse width
0x0002 use dwell for pulse width
0xFFFF a very long ~52ms pulse
0x0000 channel disabled
0x0000 channel disabled
0x?? checksum
0xCC stop
Modify to suit your needs! :-)

Fred.
Last edited by Fred on Fri Aug 09, 2013 5:33 pm, edited 1 time in total.
Reason: Replaced old payload ID
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
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

dandruczyk just pointed out that I don't give an example of how to configure input event numbers in a valid way.

For the above packet, valid values to use (for any of the string of 6 zero bytes) are 0x00 to 0x13 (0 - 19), IE, anything less than the number of simulated input events.

Thanks Dave!

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
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

A UI for it as it stands would contain the following elements:
Fred wrote: 0x01 mode - FIXED for now. No UI component required as all other values produce errors and this could change in future versions anyway.
0x14 events per cycle - CONFIGURABLE 1 - 255 are valid values
0x0010 cycles - CONFIGURABLE 1 - 65535 are valid values
0xFFFF ticks per event - CONFIGURABLE <1000 - 65535 Will return an error if too low, low value end point could change, make free form.
0x00 0x00 0x00 0x00 0x00 0x00 event to fire from - CONFIGURABLE each byte is separate, 0 is always valid, upper limit is one less than events per cycle value above, in this case 0x13 or 19, these control the pattern of order and relative timing that the pulses happen in.
0x0100 a very short pulse of 256 0.8us ticks (visible on an smd led in daylight) CONFIGURABLE see below:
0x0001 use refpw for pulse width CONFIGURABLE see below:
0x0002 use dwell for pulse width CONFIGURABLE see below:
0xFFFF a very long ~52ms pulse CONFIGURABLE see below:
0x0000 channel disabled CONFIGURABLE see below:
0x0000 PW source control or value CONFIGURABLE 0 - 65535 Values larger than ticks per event * events per cycle will result on 100% duty. Will return an error if the value is too low and not special, low value end point could change, make free form.
In summary, without the descriptions and limits etc, nice and simple:

3 individual values, 1 * 8 bit, 2 * 16 bit.
a set of 6 8 bit values
a set of 6 16 bit values

I can mock something up if it's not clear from the above.

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
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

Marketing blurb and approximate specifications:

From a single pulse test to a 10 day test!

Up to 65535 cycles
Higher than 1kHz max frequency
Lower than 0.1Hz min frequency
Lower than 1us granularity

Perfect for testing injectors, coils and output circuitry!

:-)
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
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

As UI icing, the following could be calculated and displayed:

Cycle Time Period, us, ms, s, whatever
Test Run Length, ms, s, hrs, whatever
For each pw field, duty cycle, or NA if a calc mode is chosen (1/2) or OFF if 0 is entered.

Fancy stuff is purely for bonus points, though :-)
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!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: Bench Test Decoder

Post by dandruczyk »

OK, you're JUST not getting it..

describe the UI that YOU want to see and use, as well as the basic underlying verification the tuning front end MUST do in order to send "good data" to the device.

i.e.
I want text entries for this, this and this together, and these other ones below in a list, and when I click send it MUST check X y and Z for the folowing constraints, and so on and so forth.

I have ZERO IDEA what you WANT to see, so without some "I want it to look like this" direction, its never going to happen. The more useful info you provide the faster it'll get done. I'm not a mindreader, nor have I come up with any decent way to put together the bits youve put into any sort of UI.

Even a stupid sketch on a napkin would be helpful, but try and do better than that....
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

http://stuff.fredcooke.com/bench.test.ui/

Just add CSS :-p

I'm a programmer, not a graphic designer, my idea of what I want to see is embodied above with "CONFIGURABLE" - IE, if each thing can be adjusted, within the FULL range of the variable, not limited artificially with constraints, I'm happy. How it looks is not relevant to me, only you, hence I give you the artistic freedom that I would like if I were in your shoes. The firmware will handle bad values gracefully, or you should file a bug report.

There goes another hour!

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
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Test Decoder

Post by Fred »

Two further packets are now available and the original one has been renamed!

Code: Select all

fred@roadeee [09:05:17]:test.packets$ l request.bench.test.*
-rw-r--r-- 1 fred fred 48 2011-08-18 21:08 request.bench.test.assorted.bin
-rw-r--r-- 1 fred fred 48 2011-08-26 08:46 request.bench.test.parallel.bin
-rw-r--r-- 1 fred fred 48 2011-08-26 08:59 request.bench.test.sequential.bin
They are as they say they are! All 6 channels together and all 6 channels in an even sequence.

PS, there is a bug in the module that makes it make extra outputs. sim just found this and I'll fix it asap.

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!
Post Reply