Show Posts
Pages: [1] 2 3 4
1  Development / Other Software Development / Re: SoftwareSerial magic numbers on: January 30, 2013, 12:33:11 am
So far so good.  7800 seems to be decoding messages without any errors and without my timing hack which was necessary at 9600.
2  Development / Other Software Development / Re: SoftwareSerial magic numbers on: January 29, 2013, 03:02:42 pm
I haven't even begun to think/worry about that yet.  Hopefully it just works.  Ha!

In all seriousness, I'm literally waiting for FedEx to deliver my 'scope (hopefully Friday) so I'll have a better idea then for what I'm dealing with.  I do know that at 9600 baud it seems to kinda-sorta work, but I do seem to be getting some corruption, but that mostly seems to be due to the timing differences from what I can tell/guess.  So it appears the line is pretty clean. 

That being said, I haven't tried it with the bike actually running yet, so things could get a whole lot noisier once those coils start firing.
3  Development / Other Software Development / Re: SoftwareSerial magic numbers on: January 29, 2013, 01:32:08 pm
Hey Rob, I just wanted to say thank you for your research on this.  As it turns out I have a need for SoftwareSerial to do 7800 baud to read from a motorcycle ECU->Dash communication link and it sounds like you've solved my problem. smiley
4  Development / Other Software Development / Re: Using SoftwareSerial with custom baud rates on: January 29, 2013, 01:17:12 pm

Thank you!  I found that thread and based on the results it should do exactly what I need. smiley  I'll give that a try tonight when I get home.
5  Development / Other Software Development / Using SoftwareSerial with custom baud rates on: January 28, 2013, 04:39:37 pm
So I see (new)SoftwareSerial only support the common baud rates and each supported baud rate needs to be defined in a table in SoftwareSerial.cpp.

I'm trying to figure out how to add support for 7800baud.  I sorta figured the rates would be linear (9600 would be 1/2 of 4800) but that doesn't seem to be the case.  How can I calculate the appropriate timings?  I know my Uno runs at 16Mhz so hopefully that's fast enough to get within the 2%, but lucky for me each message is repeated constantly (10x per sec) so if I get out of sync I can always throw away that 8 byte message and wait for the next one and I only need to be able to read, not write.

Thanks for any hints and advice!
6  Using Arduino / Project Guidance / Re: Talking to an automotive ECU on: January 26, 2013, 02:49:42 am
Good news.  Fully able to read the ECU data stream.  Have to set the SoftwareSerial to 9600 baud (nothing else works at all), and I'm getting some odd timing errors, but I've been able to work around them so far and I'm so far able to parse the messages. 

USPS wanted a signature for the logic analyzer and I was at work so didn't get it yet- so not able to compare the actual data stream to what the arduino is reading, but so far so good.  Thanks!
7  Using Arduino / Project Guidance / Re: Talking to an automotive ECU on: January 25, 2013, 11:17:21 am
You said,  you didn't see anything at all.

And then you said,  some bytes are missing .

To me that seems inconsistent.   Are you seeing anything happen,  what do you see ?

If I run at the same speed as the Arduino emulator (7800 baud, but it's using the UART) I see nothing. 

If I run at 9600 baud (emulator still at 7800) then I get data, but it seems corrupted.

Here's the emulator code I'm using:
8  Using Arduino / Project Guidance / Re: Talking to an automotive ECU on: January 25, 2013, 02:24:51 am
Hmmmm... we'll I've got something that I thought should work but seems pretty broken:

I tried hooking it up to the ECU and no luck at all... doesn't see any packets at all.  If I hook it up to another Arduino running the simulator code I saw on the SV forum, it sees data; but only if I change it to 9600 baud (the emulator is running at 7800?)   Even then though, things are broken- seems like I'm missing occasional bytes on the wire and looks like the data is corrupted.  

Not sure if this is a limitation of the SoftwareSerial library or if my code is subtly broken.  I looked at the limitations about the library on it's web page, but since I'm using an Uno and only one pin for serial, it doesn't sound like either apply to me.

Anyways, hopefully the logic analyzer I ordered shows up tomorrow and I can see the ECU protocol for myself rather then relying on some descriptions by other people.  
9  Using Arduino / Project Guidance / Re: Talking to an automotive ECU on: January 24, 2013, 05:00:44 pm
So I did more reading on interrupts... sounds like they only work for digital pins, so probably not viable to deal with both inputs asynchronously.  Guess the easiest thing is to just do something like this:

int last_ms = millis();
void loop() {
   if (ecu.available()) {
      ms = millis();
      delta = ms - last_ms;
      if (delta < 20) {
          # process byte
      } else {
          # process message
    } else {
        # read analog pin
10  Using Arduino / Project Guidance / Re: Talking to an automotive ECU on: January 24, 2013, 04:32:41 pm
Yeah, it's not LINBUS or CANBUS.  It's single wire, uni-directional and point-to-point.  The message format is very simple.  First two bytes are water temp, followed by a bit mask for various error codes and the last byte is a simple CRC.  Even the tachometer is on a separate line and is a different protocol.

This thread on SV Rider has the details if you're interested:
11  Using Arduino / Project Guidance / Talking to an automotive ECU on: January 24, 2013, 02:10:44 pm
So I want to use an Arduino to process a serial data stream from a motorcycle's ECU (Suzuki SV650).  The data stream is what the ECU sends to the dashboard.  I already know that the stream looks like:

10 messages/second @ 30ms apart
each message is 8 bytes @ 10ms apart

I need to process the 8 bytes together (last byte is CRC) and do some quick parsing to illuminate an LED/7 segment display.  No big deal.

So far the best idea I've come up with is using SoftwareSerial (I have an Uno and I want to use the USB serial for debugging) to read the bytes and just measure the time by calling micros() each time to measure the delta between bytes to figure out where I am.  Seems kinda hackish, so I figured I'd ask here if there are better ways.

One thing I'd like to add in the future is to process a 2nd analog line and output on a 3rd analog line.  Basically I want to fake the ECU into thinking that there still is an electric motor and it's position sensor are still attached.  Not sure how quickly I need to respond to it's inputs to keep the ECU happy (technically there shouldn't be any lag, but I'm sure it would be OK with some), but 10-30ms might be too much???

I've heard about programming via interrupts before- maybe that would allow me to do both on the same Arduino elegantly?  Not sure what kind of limitations that has?

Anyways, looking for advice on how to proceed and any links to things I should read about.  Thanks!
12  Using Arduino / Microcontrollers / Re: Arudino Bootloader/Code on other ATMega chips? on: May 03, 2011, 10:14:07 am
Sounds like the ATmega1284 would be a simple drop in replacement.  And if I didn't want to learn SMD I still have a DIP option too.  Sweet.  Thanks for the replies!
13  Using Arduino / Microcontrollers / Arudino Bootloader/Code on other ATMega chips? on: May 03, 2011, 01:03:03 am
I've been looking at taking my Arudino Uno based project to a custom PCB for a number of reasons.  One of which is I've run out of flash memory for handing both an SD card and LCD.  I suppose I could use an ATmega2560/V chip like in the Mega board, but then I'm looking at 100 pins or so which seems a bit more complex.  The AT90USB1286 has only 64 pins and plenty of flash/ram for my application and has direct USB connectivity.

AFAIK, none of the existing Arduino boards use the AT90USB1286 or any chip from that series, so it is unlikely that I could just use the Arudino bootloader.  Is that right?  Honestly, I'm not 100% positive what the bootloader does- or if there are other ways to run code built with the Arduino SDK.  Looks like the Teensy++ 2.0 board uses this chip and it sounds like it's from a software perspective compatible with the Arduino?

Hoping someone can point me in a direction of a FAQ or HOWTO which explains how to move code which was running on an Uno board to something like the AT90USB1286 or if it'll never work and I should just plan on learning to solder a 100 pin SMD part.  I'm pretty familar with Makefiles, compilers and I'm not afraid to drop into a shell to get a build environment working- I'm just at a loss right now what path to take.  Seems like I need a way to get the boot loader installed and then program it?


14  Using Arduino / Sensors / Re: LM34 temp creep due to sun/selfheating? on: April 11, 2011, 12:18:27 pm
Yeah, I get that... just that it's heating too fast IMHO- a couple of minutes for 40 deg change on a cool day with a slight breeze?  Seems unlikely.  It didn't feel warm, and if you've ever owned a black painted car you know it takes longer then that to warm up.

Honestly, I started having problems with the thermistors shortly there after as well... not sure what was going on, but all my analog readings became suspect after a while.  Was too busy smoking the brisket and getting ready for the party to start debugging.  Maybe I have a short or a bad ground... it's definitely a lot harder to keep all the wiring nice and clean one a perfboard then on a breadboard.

Hopefully I can figure it out and get things working properly- I've spent a lot of effort getting the thermistors to work and switching to thermocouples would not only be expensive, but end up costing a lot of time.
15  Using Arduino / Sensors / Re: LM34 temp creep due to sun/selfheating? on: April 10, 2011, 04:42:14 pm
Good point about the voltage.  I'm not using an arduino board for this, but I do have AREF tied to ground w/ a .1uF cap.  My Arduino usually measures about 5.02V while this power supply is about 4.96V. 

I've been reading about the AREF pin... mostly seems used to measure values less then 5V since the default is to use the internal 5V reference voltage... I'd assume though that's just reading the voltage off of AVCC/VCC?  Is there any reason to tie the AREF pin to the 5V power supply?

Here's the circuit... right now I'm not using the MAX756 for power- just a sparkfun breadboard power supply.
Pages: [1] 2 3 4