IOx Basic a.k.a. IOx-OEM

[Rod S]

Jean,

Returning to this point from one of my earlier questions....

All 24 ADC ports are available and the logger board actually uses 13 of them: 8 for EGT, 3 for the accelerometer, 1 for 12V and 1 for 3.3V. Those are also hardcoded in the code but can be used with the IOx-OEM.

I can see this here,



1 - When you say they are "hardcoded", what does that actually mean ? Does it mean they are permenantly associated with defined CPU ports (which you have hardwired on your EGT board), or somthing else ?

Then, when I asked if the remaining (ie, beyond the ADC 0-7) could still be used you also said,

The only way to collect data for the remaining 16 ADC channels is to do a datalog of the IOx data. I'll have to see if the data between the 2 devices can be correlated in TS and/or MLV. But TS does collect the data on all the CAN devices in a project (actually, that can be disabled now).

Now does this mean, for example, that ADC channels 8,9,10,11 can only be logged as EGT data and cannot be displayed ? Also, when logged will they be fixed with the title of EGT ?


The reason for asking is that on my carrier board, I have "hardwired" it as far as possible using exactly the same CPU ports as you use on the full size IOx (to avoid confusion) as follows,

Trying to ignore the difference between numbering (1-8 = 0-7 depending on where you look......)
Six generic analogue inputs wired as per your ADC 1-6, same CPU ports as per the table (ie, wired to ADP10, ADP19, etc.)
The CPU ports you would have had wired to ADC 7 and 8 left unconnected so ADC 7 and 8 can be allocated for Innovate dual wideband.
Three generic medium current outputs wired as per your Hout 4,5,6 (ie, wired to PTD1, PTL0, PTG4)

Now for the confusion.....

I have added four more analogue inputs, hardwired for temperature only (uses less parts than providing the "generic" option) and,

a - I would like to allocate them to ADCs 9 - 12 (8 - 11 in the screenshot) basically becuase you only have three remaining spare numbers, not four.

b - I would like to use other ports simply for board layout.

What I'm unclear about is whether I have to use the same physical ports as you use for EGTs 1 - 4 because of this "hardcoding". I can see others available in TS to allocate to ADCs 9 - 12 but I know you said earlier (somewhere) certain allocations should be grayed out but aren't.

If so, presumably the CPU ports you use on your EGT board are as per the table (ADP 9, 0, 4, 18). If it's possible to use the same ones I will anyway (just to avoid confusion) but I am very limited on board space now. Ideally I would like to use some different ADP ports, but they are allocated different ADC numbers in the table.

Hope that all made sense.

Rod.

EDIT - to try and make more sense.

[Rod S]

post in error, ignore/delete

[jbelanger]

Rod,

I see from your last message that things are clearer for you. However, I just want to make it clear for everyone else that all the ADCs are available for any function and that there is no hardcoding in the IOx for what each ADC can do. The functions listed in the activation screen are the ones from the IOx and logger board circuits but that doesn't change how the ADC is read or how the data is stored in the IOx (always raw ADC count).

Now to potentially add to the confusion, I have a new firmware available (viewtopic.php?f=9&t=963) that removes the hardcoded ADC mapping so that you can use any ADC pins on the ADC channels. So instead of using the mapping shown in my previous post, you can use any ADC pin that makes sense for your board layout and use the order that makes sense for each ADC function depending how you want to transfer and use the data over CAN. That should simplify the use of the IOx-OEM and make it more flexible. Hopefully that's not too confusing.

Jean

[Rod S]

Thanks Jean,

All beginning to make sense.

Despite the new firmware, I've decided to keep the same ADC/ADP as per the original table.

I've used 4 wire jumpers as I can't get tracks in the right place, a terrible sin but the MS2 is covered with wire jumpers and it's a four layer board, and I'm only using a two layer

I already had to have one wire jumper for the 12V to the CAN socket (to match your protocol for a 4 wire CAN cable) so four more small ones isn't a big deal.

Quick preview without ground planes.



I need to add about 30 - 40 ground vias, not easy in KiCad, to get contigious ground planes both sides, sort out all the labelling, then it's good to go to iTead.

12V in on a molex or in/out from a nearby PCB
Most Inputs/outputs on a DB15
USB (sparkfun plug-in board)
I2C on a pin header (for 14point7 SLCs - just need to add the terminating resistors)
RS232 (for Innovative widebands) on a 2.5mm jack
CAN, per your protocol, on a 3.5mm 4 pole jack (or a pin header)
six generic analogue inputs (DB15)
four analogue inputs (temperature configuration only)(DB15)
three medium current switched outputs (DB15).

100 x 60 PCB.

I didn't use the SOIC8s you suggested to me by email for the outputs, even with my double MaGoo glasses, I avoided them

Rod.

[jbelanger]

Nice setup. And since you are putting the IOx-OEM upside down on your board to keep the overall height as low as possible, that's going to show the 'jbperf.com' logo on the bottom of the board

One thing I'm not sure about is your mention about the I2C terminating resistors. Do you mean the pull up resistors?

Jean

[Rod S]

Nice setup. And since you are putting the IOx-OEM upside down on your board to keep the overall height as low as possible, that's going to show the 'jbperf.com' logo on the bottom of the board

One thing I'm not sure about is your mention about the I2C terminating resistors. Do you mean the pull up resistors?

Jean

Yes, sorry about the flash reflection in this photo, but your logo is clear



This was just to make sure I had the IOx and sparkfun board located right. All the space to the right is for another board for the 14point7 modules.

It's amazing how many other bits I can fit in below your PCB and the Sparkfun PCB even without resorting to SMDs.


And yes, I meant pullup resistors for the I2C, it's getting late over here in the UK so my posts may become eratic

[Rod S]

First version of carrier board arrived from iTead today - took ages longer than usual but seem good quality.

Only a prototype so I have an improved version to follow once I've tested this one (well 12 of them actually.... that's the way iTead work...)



I'll assemble/test later this week.


What I've squeezed into a 60X100 board is the IOx-OEM itself, a Sparkfun USB board, RS232 serial, two sockets for the RS232 and also for I2C (using Jean's protocol), six anything ADC inputs, 4 temperature only inputs, and three medium current outputs.


Obviously it all needs assembling/testing but my plan is to use this along side a 100x100 board (also arrived today) with some 14point7 SLC wideband modules and some EGT thermocouples. thus giving me a 100x160 complete package.

There seems to be some issues with the 14point7 stuff at the moment but hopefully that can be resolved soon.

[jbelanger]

That looks good and I look forward to seeing it fully assembled and seeing the results.

As for the SLC OEM, I also hope to resolve the issue or at least get some feedback on it.

Jean

[Rod S]

Partially assembled (need some more parts, hopefully with me tommorow)



Your logo is nice and clear Jean

[jbelanger]

Looks good! Nice logo

[dontz125]

As for the SLC OEM, I also hope to resolve the issue or at least get some feedback on it.

Hi, Jean.

Like you, I'm not happy about the re-flashing aspect of the SLCs, but Alan has addressed the matter of forcing I2C and clarified a typo - http://14point7.com/forum/index.php?topic=2507.msg9458#msg9458.

How will this affect the use of the IOx-OEM with 2x SLCs and an MS2/x? Identities will obviously be '0001' and '0010', at the least.

[jbelanger]

Don,

Actually this was my proposal to resolve the I2C issue of sharing the lines with the calibration function.

So what I will do is that the IOx code will use addresses 16 to 23 (10000 to 10111). Bit 5 will be the one bit that is always set which the best workaround solution for the few boards that are already in the field. It simply requires a jumper to that 5th pin. Hopefully that will not be an issue for your hardware but I know Rod's board will need a jumper, at least in the current version.

Jean

[dontz125]

Perfect - I have 5 solder pads for each SLC.

[Rod S]

but I know Rod's board will need a jumper, at least in the current version.

Yes, but when you said jumper it made me re-read my notes.

I had intended to pull the relevant address pins high with resistors - but I see you say in a much earlier thread that isn't necissary (I allways thought it was good practice ?) but either way, there is enough space between the underside of my board and the base of the case to solder either a wire or a resistor to the 5th pad location.

And it is a "prototype" - at the end of the day there are bound to be other errors I've made which will cause me to re-design it.


Re the firmware, I think it is a copout by Alan because he doesn't want to encrypt it. I looked at TechEdge's site (as I currently have TechEdge conrollers) and the latest firmware is all there to download, just encrypted to protect their "intellectual property".

Posting the module(s) back isn't expensive, even from the UK, but is a very long wait and isn't particularly sensible once you've soldered header pins/sockets to the card. And what if a customer doesn't bother with a plug/socket arrangement but just pins them direct to a carrier board ???


Rod.

[Stu_D]

Hi Jean

I have just quickly mocked up a schematic in EAGLE to use a IOx Basic to connect two SLC_OEMs to my MS2. JP1 JP2 and JP4 have been removed from my PCB footprint to clean up the PCB slightly and because i have no need for any other I/O and have no plans for further expansion on this project.

I was just about to contact you about purchasing a IOx Basic but while reading through your Ruggedized ECU thread, at the bottom of page two i saw you have mentioned what you describe as a minIOx for the additional I/O. Are you ever likely to produce a minIOx Basic?

The IOx Basic is great, but for my needs it is total overkill and a minIOx Basic would be much more suitable, however even that might still be a bit overkill.

Screen dump of the Schematic


Thanks

[jbelanger]

Stu,

I haven't decided yet if I will have a mini-IOx Basic any time soon or even at all. While I understand that the IOx Basic is overkill for most it does allow all the IOx features and that wouldn't be the case of the mini-IOx. And it doesn't make sense financially for me to have many very low volume options. There is also additional costs in the additional maintenance and support.

Jean

[Stu_D]

Yes i totally understand where you are coming from, it makes perfect sense for you to keep the product lines similar so that they use the same hardware and code. It will make your job providing support as simple as possible while providing the widest set of features. I thought this would be the case (you seem to have enough on your late at the moment as it is!) but if you don't ask you never know.

Could you please PM me details on how to purchase one of these please?

Thanks

Stu

[jbelanger]

PM sent.

Jean

[Arttu]

Hi,
I'm designing a motherboard for IOx-OEM. I have gone through all information that I have found about functions of the module pins. I think I have got a quite good picture about what I should connect where but I still have few open questions:
-The motherboard will have a serial port for external GPS or Innovate wideband. Or whatever possible use. Which port I should use for this, port 1 or port 2?
-Are there additional timer input channels available for frequency/pulse measurements in addition to those four that are used as VR inputs on the I/O Extender?
-Are there additional PWM outputs available in addition to TPM1CH0, TPM1CH1, TPM1CH3 and TPM2CH1?

I also attached a spreadsheet with pin listing of the module. I have filled in all information that I have found about functionality of each pin. I have also listed there how I'm going to use each pin. It would be great if you could check it through and tell if I have something wrong. I guess this sheet could be useful for other users as well when filled completely.

Thanks in advance!

[jbelanger]

I will have a better look at the spreadsheet but from a quick look it seems ok with a few exceptions.

The serial port to use for LC1 or GPS is port 2. Port 1 is used to communicate with the IOx or, in serial passthrough, to communicate from a PC to an LC-1 or GPS connected to port 2. The IOx forwards the data from one port to the other in serial passthrough.

The only timer input available for frequency/pulse measurement are the 4 timer 3 channels which are connected as VR input on the IOx. And they can only be used for that.

All the channels from timer 1 and 2 can be used for PWM outputs. So that allow up to 8 of them.

the I2C bus 1 (SDA1, SLC1) is used for the RTC, The I2C bus 2 is used for the SLC-OEMs.

Jean