external ADC

[kb1gtt]

On OEM discovery board we are running short of chip select lines, hence the 176 pin brain board. Getting many channels in one chip is handy as it would require less CS lines.

[puff]

how many chips with cs lines are there on the daughter board?

[kb1gtt]

good point, the quickfilter 4 channel chip would require 4 chips to get 16 channels. It offers 512 tap filtering and a bunch of nice options, but would require many CS lines. While a chip with out the filtering would allow a trade off of less CS lines. I guess it depends on if the chip is used for the existing discovery board, or a different board with more IO.

So I guess we should split this into two items of interest. One is for an unlimited IO were we are aiming for best features, like we might do with an FPGA or the 176 pin STM. The other option that I think we have interest in, would be a better replacement for what we have on the frank boards. The op-amp is kind of bulky and has many parts. It would be nice if we could maintain the rugged nature with less parts or with less cost.

Current features of the op-amp buffered A/D include, low pass filtering, over voltage protection, under voltage protection, scaling the voltage from 18V to 3.3V, optional pull up or pull down resistors and impedance matching the STM's input. Can we find a better way to do that? Can we find a better way to do it if we aren't concerned about the number of CS lines?

[Sync]

I guess we could just daisychain the external ADCs and use DMA as abecedarian said.
That way the ADC is running completely alone without robbing computational power. The software just looks at the right place for the values and does what it needs to do.

Can't we just use the internal ADC? We have 16 channels and enough speed to stay above 10kSPS at 12bit and 16 channels.
The ADC is connected to APB2 which is clocked at 84MHz max, ADCCLK is Pclk2/2 at best, so 42MHz. Conversion time is 15ADCCLK cycles,
giving us 2.8MSPS. Divide that by 16 channels we get 175kSPS (per channel!) - DMA overhead.

With some careful attention to how the timers are set up, we should be able to put the different channels into appropiate scan groups to always have the currently important data ready in the memory.

Sources: Reference manual around page 400 and datasheet page 14.

[kb1gtt]

This tread was partly sources by a different thread about FPGA, which of course needs an external ADC. This tread was partly because we have many ADC components to buffer, scale, anti-alias, ect. Part of the conversation was to research if a chip could make our ADC situation better, part of it was to talk about a potential for FPGA like applications. Neither situation is likely to happen any time soon, it was just generic talking.

[chingon]

Any chance we can have it transceived to CAN? Don't know if there's a chip that's both ADC and transceiver in a common package, but would make things compatible w/other systems if you wished to expand customer base. Obviously if you wished to not limit to one protocol and/or baud rate, an 'optional' transceiver (via jumper maybe) would be nice.


maybe even excitation voltage

[kb1gtt]

We plan for a version of this board http://rusefi.com/forum/viewtopic.php?f=4&t=769 to be a remote sensor via CAN option. It has ADC capabilities. The CAN protocol has not been determined. If you know of a protocol that might work well with existing devices feel free to comment and steer us in the effort.

[chingon]

http://www.nxp.com/products/microcontrollers/product_series/lpc1100/series/LPC11C00.html
http://www.nxp.com/documents/leaflet/75017050.pdf
http://www.mouser.com/new/NXP-Semiconductors/nxplpc11c22lpc11c24/

althought 10 bit ADC's are kind of weak


CANOpen is an open protocol but not as widely implemented. Seems like most of the industry will stick w/CAN and/or CAN-FD

[AndreyB]

Any chance we can have it transceived to CAN? Don't know if there's a chip that's both ADC and transceiver in a common package, but would make things compatible w/other systems if you wished to expand customer base. Obviously if you wished to not limit to one protocol and/or baud rate, an 'optional' transceiver (via jumper maybe) would be nice.)

I want to make sure I understand your suggestion.

Are you suggesting an external ADC which would be talking to rusEfi via CAN? Are you suggesting to build a tiny ADC+CAN board to talk to rusEfi and anything (what exactly?) else? Are you suggesting consuming voltage information from CAN while something else would be providing it?

[chingon]

Any chance we can have it transceived to CAN? Don't know if there's a chip that's both ADC and transceiver in a common package, but would make things compatible w/other systems if you wished to expand customer base. Obviously if you wished to not limit to one protocol and/or baud rate, an 'optional' transceiver (via jumper maybe) would be nice.)

I want to make sure I understand your suggestion.

Are you suggesting an external ADC which would be talking to rusEfi via CAN? Are you suggesting to build a tiny ADC+CAN board to talk to rusEfi and anything (what exactly?) else? Are you suggesting consuming voltage information from CAN while something else would be providing it?

Yes to the bold part. Basically sensor info transmitted over CAN to rusEFI to be logged/used as needed (feedback for tuning if need be). As far as the excitation voltage, it'd be for active sensors such as strain based/pot/linear/etc... Isn't what this thread is all about?

receiving can frame is useful for sensor offset adjust (zero in). would allow users to daisy chain multiple modules if need be.

[AndreyB]

the original focus was on 5v ADC so that the dividers are not required. The idea to use LPC11C00 as such an ADC would be beautiful but only if it would be a 5v chip - looks like it's not

[chingon]

the original focus was on 5v ADC so that the dividers are not required. The idea to use LPC11C00 as such an ADC would be beautiful but only if it would be a 5v chip - looks like it's not

Honestly, I'm very green at this so just pasted the 1st one google spit out. Which turns out to be a relatively ancient mcu...
http://www.nxp.com/documents/data_sheet/LPC2109_2119_2129.pdf is a newer one and seems to tolerate 5 v

http://www.nxp.com/documents/data_sheet/LPC1769_68_67_66_65_64_63.pdf
still seems to need dividers...but at least 12 bit adc's.

http://www.analog.com/media/en/technical-documentation/data-sheets/ADUC814.pdf
6x 12 bit adc's 5 volt capable, 8 bit mcu, and no CAN on chip

http://www.freescale.com/files/32bit/doc/app_note/AN4442.pdf

maybe worth a look at pre-fabbed shields?
http://rascalmicro.com/docs-precision-voltage-shield/
http://store.rascalmicro.com/
pricey, but didn't do much digging
https://www.adafruit.com/products/1085
http://www.adafruit.com/products/1083?gclid=CN6Fi7yM68UCFQYxaQod_ogAuQ

[AndreyB]

http://www.nxp.com/documents/data_sheet/LPC2109_2119_2129.pdf is a newer one and seems to tolerate 5 v

"The ADC pads are 5 V tolerant when configured for digital I/O function(s)."
Only in digital I/O mode, so looks like not a 5v ADC.

Unless we find a magic chip with 5v ADC and CAN transceiver on board I doubt that CAN path would make sense

[puff]

CAN adds up latency, while for many of the sensors you want to avoid it… I guess this refers to any 'digital' sensor.

[chingon]

http://www.nxp.com/documents/data_sheet/LPC2109_2119_2129.pdf is a newer one and seems to tolerate 5 v

"The ADC pads are 5 V tolerant when configured for digital I/O function(s)."
Only in digital I/O mode, so looks like not a 5v ADC.

Unless we find a magic chip with 5v ADC and CAN transceiver on board I doubt that CAN path would make sense

Yeah, seems like all the 5v ADC/MCU combos don't have CAN built in. I still think you'd find a market for it (outside of Rusefi), if a CAN chip was built on the board and data could be sent over it. There's plenty of systems w/CAN input but not enough AD's built in, and many more loggers looking to capitalize on it as well (looking at aimsports/mychron,racecapture pro/autosports AEM/daq1, racelogic, ipetronik, csm, who all have adc to can offerings or inputs).

Then again, you'd have to come up w/a .dbc file creation software, or a configuration scheme of some sort.

If it was bypass-able for Rusefi use, and prevent the bottleneck that CAN gives, it'd be the best.

[kb1gtt]

Frankenso includes a CAN option. It includes 5V, CANH, CANL and GND. The 5V can support around 1.5A to 2A, so it can provide a communications channel as well as a power channel. CAN has been used to control an OEM digital dash. That's needles (RPM, Tach, voltage, temp, ect) as well as digital signals, and check engine lights.

[chingon]

Frankenso includes a CAN option. It includes 5V, CANH, CANL and GND. The 5V can support around 1.5A to 2A, so it can provide a communications channel as well as a power channel. CAN has been used to control an OEM digital dash. That's needles (RPM, Tach, voltage, temp, ect) as well as digital signals, and check engine lights.

I understand that, I guess what I'm not getting is, if this is an external ADC unit, and not an internal shield/board, why not expand the user base by making it CAN friendly? What digital 'protocol' is it going to use to communicate with rusefi?

CAN is less than ideal, USB probably most throughput; but I propose having the option to toggle and send over CAN would really expand user base

[AndreyB]

why not expand the user base by making it CAN friendly?

Supporting a product is a nightmare. I am wasting time on rusEfi mostly because I am bored. Marking a small expansion ADC 2 CAN board is just not my thing Too much hustle with logistics and user support and warranty etc. etc. etc.

We have all the pieces to design one, but I am not sure if I have the motivation.

[chingon]

why not expand the user base by making it CAN friendly?

Supporting a product is a nightmare. I am wasting time on rusEfi mostly because I am bored. Marking a small expansion ADC 2 CAN board is just not my thing Too much hustle with logistics and user support and warranty etc. etc. etc.

We have all the pieces to design one, but I am not sure if I have the motivation.

Fair enough, as long as it remains open source I'm sure someone could always take it in that direction if they chose to. Just thought the extra revenue (if any) could come in handy to push Rusefi a little further.

[Tomin]

I am for simple "protocol" on CAN like is described here:
http://rusefi.com/forum/viewtopic.php?f=13&t=751&p=13050#p13036
It is fully usable and simplest.

[mk e]

This is old but as I work to install an I/O expansion on my non-rusEFI setup I realized the MS solution to expansion is a FW change in there microsquirt....ECU-I/O expansion-TransControl

Is that something you guys are thinking about, might be thinking about, or already have and I didn't see it? I did see talk the the WB control might be CAN friendly.

With CAN up and running the options become nearly limitless I guess..the motec crowd mounts the ECU then a PDM (power distribution module) front, back , middle so installing new stuff becomes dead simple as power, ground, signal are never more than a few feet away. I've not really gotten on the train yet but did include a CAN line to the front when I built my wire harness should the time come when I step out of my hardwired world.