bionicmotronic

Thanks Hanz. Will look into that. Sounds like great solution. Will look into that.  (yep old Audi I5 20V) 

Hi!

Why not multiplex the 12 using only a single voltage divider and analogue input?

You'd have to sample 12 times as often but it would be very economical...

About the relays, pretty much the same deal or use a latched shift register.

EDIT: Your avatar looks like a turbo charged in-line four jap motor or an old BMW M3, but what is it?

EDIT: If its for a motronic application, speed could be a problem.

Thanks for resply Hanz.   In order...

• That sounds like a fine idea, but what would I Mux w/?  An external mux IC that could handle the voltage if I understand you right?  If so I'd still need some suggestions of what to look at to do that...
• Ha. Not quite. Hint - "the other Bavarian"  
• Bing yes is for a Motronic application, however it is NOT realtime running-engine issues so  precision and speed doesn't have to be immaculate - I know Netduino isn't ideal for that. I already have a rig I built for rudimentary booting and logging into and limited output tests of old OEM ECU's but I really want to be able to monitor the output lines and basically log the triggers to confirm that the various drivers have basic function and report voltage output for each.

Any specific suggestions / ideas would be great - again some outputs will be as much as 13.5 volts... and speedwise something like a simulated 2k RPM signal would be at most say ~33-50hz (and often the signals will be 1/2 that - ~16-25hz aka 4 stroke engine with various triggers occuring only 1/2 the revolutions) so really super slow as far as even a weak micro is concerned... 

Given that there are I2C problems in the original firmware I would suggest that you upgrade to the latest firmware as per the update article.  It's not too difficult and only takes five minutes or so.

 

At least by doing this you know that any issues are less likely to be firmware related.

 

Regards,

Mark

Totally nailed it Mark.  I thought I was at latest firmware but I was wrong and boy that is the big difference.  THanks!

Erm, basic documentation like here? http://netmftoolbox....ailable classes 
I have planned to do a small video tutorial too by the way.

 

The shield should work fine with a NP2. The only issue I am aware of is that, after some period, characters can become scrambled.

But that's not what you describe.

 

Please try that sample code, that should work.

 

 

-edit- Mark has a point, you'll need the latest Netduino Plus 2 Firmware.

Stefan -   Thanks much for all the work and examples into the toolbox - didn't mean to criticize.  I saw your video on "how to install" and that was very simple in terms of running the installer, then I had to go find:

http://netmftoolbox....se the classes?, which for some reason as a n00b I found  just a bit trickier to stumble on from the docs page.   And since I knew if I was going to VB I needed to use the DLL's, I looked at that part which talks about using a zip file for the DLL's.  I was pretty sure that was obsolete and that the Windows installer program had already installed them for me (which of course it had) so then I just had to go back and re-run the installer and actually pay attention this time    to what path it was using... once I had that path so I knew where the DLL's were dumped, I could add the references easily. 

And then the VB code example for this particular item didn't explicitly show the Imports line - I just found another VB example with it...   I had seen the link you reference but wanted to be sure I had the Import name correct - as I said found plenty of examples with a little poking around.  

As above - working great now!  Just wrote some profanity to my display.  Works great! Thanks again for the work on the Toolbox.  Super cool resource. 

Thanks for replies guys.  

Really for the language differences, it comes down to in C# things need to be explicit and VB things are implicit.

I strongly prefer C# because it is explicit, most decisions are ones that you instigated, whereas in VB you get a more stuff that happens when you didn't actually want stuff to happen.Therefore lots of weird errors.

Also in VB you have to write Dim too many times.

 

One advantage of VB is the For Next loop operators seem to work more easily with the iterators.

 

That's my 2c.

Yeah in VB I always use Option Explicit anyway, so that should be "about the same"

I do have these weird "overflow will not throw exception" errors that appear and disappear, but searching around that seems to be a VB anomoly... maybe I'm still not doing something right but the code seems to work fine. 

Firstly, my personal preference is C# but I'd advise that you go with the language you feel the most comfortable with.  One thing you will note is that there are more C# examples out in the forums than VB.NET.  At some point you will probably have to get comfortable with reading C# even if you do not code in it.

 

Regarding compatibility of drivers etc.  There are two things you can do here, convert the code to VB or compile the C# to a DLL and then add a reference to the compiled library in your VB project.  If you want to convert the code then there are plenty of free online translation tools which will do the job for you.

 

Welcome to the community, hope you enjoy working with this board,

Mark

I definitely have no issue reading the C#, not saying I'm great at it but I can get by.  It's just coding it fast is a different story.  It's like French - I can muddle through reading a newspaper but ask me to open my mouth and forget about it

I did some searching and see yep I can load the drivers via references.  No problem there, probably rather do that and have known-good function calls than use a translator that might muck something up.

Thanks again guys...  playing around some more today.  Fun stuff.