View unanswered posts | View active topics It is currently Tue Mar 19, 2019 3:48 pm



Reply to topic  [ 23 posts ]  Go to page 1, 2, 3  Next
Bench Test Decoder 
Author Message
Moderator
User avatar

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


Sat May 28, 2011 6:25 pm
Profile WWW
Moderator
User avatar

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


Fri Jun 03, 2011 9:12 am
Profile WWW
Moderator
User avatar

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

Quote:
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:
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:
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.

_________________
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!


Last edited by Fred on Fri Aug 09, 2013 5:33 pm, edited 1 time in total.

Replaced old payload ID



Tue Jun 07, 2011 5:32 pm
Profile WWW
Moderator
User avatar

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


Wed Jun 08, 2011 9:15 pm
Profile WWW
Moderator
User avatar

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


Tue Jun 21, 2011 10:58 pm
Profile WWW
Moderator
User avatar

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


Wed Jun 22, 2011 12:01 am
Profile WWW
Moderator
User avatar

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


Wed Jun 22, 2011 1:23 am
Profile WWW
LQFP112 - Up with the play

Joined: Sun Apr 06, 2008 6:30 pm
Posts: 100
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....

_________________
-- David
http://www.megatunix.com
http://megatunix.sourceforge.net


Wed Jun 22, 2011 1:40 am
Profile
Moderator
User avatar

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


Wed Jun 22, 2011 9:15 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15235
Location: Home sweet home!
Two further packets are now available and the original one has been renamed!

Code:
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!


Thu Aug 25, 2011 10:06 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 23 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.