Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: SCI3 bitrate for diagnostics info


Guru

Status: Offline
Posts: 2338
Date:
SCI3 bitrate for diagnostics info


The Busa ECU utilises serial protocol to send information to gauge cluster. E.g. it ransfers the engine temp, the engine fault codes and has an ability to output each individual ram variable to the serial port 3.

I have been really struggling to find the SCI3 BRR (baud rate register) from the code and experimenting has not yielded constants results so have not been making much progress with understanding the serial protocol - but today got one of these moments, why no just read it using the AUD connector... and here is the result.

SCR3 SMR,FFFFF018 = 00000000 = CKS1 = 0, CKS2 = 0
SCI3 BRR,FFFFF019 = 0000004F = dec 79

When you enter these to the below formula in excel I got a very surprising figure compared to what was expected (appr 7kbits/s which when testing did not gave any framing errors).

XTAL10Mhz
Oper frequency40Mhz
Internal clock40Mhz/2 = 20Mhz
B=((79*64*1/2))*(20000000/10000000)=5056bits/s

Have never before done any bitrate calculations, so I am a bit unsure about the result - any confirmation would be appreciaged.


7052baudrate.jpg

-- Edited by PetriK at 14:33, 2008-02-14

-- Edited by PetriK at 14:38, 2008-02-14

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

These are the running values for gauge data output:

SCI3 SMR,FFFFF018 = 00000000
 bit 7=0, Asynchronous mode
 bit 6=0, Eight bit data
 bit 5=0, No parity check
 bit 4=0, even parity
 bit 3=0, one stop bit
 bit 2=0, multiprosessor function disabled
 bit 1&0=0, Clock select is peripheral clock

SCI3 BRR,FFFFF019 = 0000004F = 5000bits/s ?????


SCI3 SCR,FFFFF01A = 00000020 = 0010 0000
 bit 7=0, transmit data empty interrupt disabled
 bit 6=0, receive data full interrupts disabled
 bit 5=1, start by setting TDRE bit in SSR
 bit 4=0, receiver disabled
 bit 3=0, multiprosessor interrupts disabled
 bit 2=0, transmint end interrupt disabled
 bit 1&0=0, Asynchronous mode, internal clock, SCK pin can be used for other purposes


SCI3 SSR,FFFFF01C = 00000084 = 1000 0100
 bit 7=1, No valid data to be transmitted
 bit 6=0, No valid data to be received
 bit 5=0, Receiving in progress has ended normally
 bit 4=0, Receiving in progress has ended normally
 bit 3=0, Receiving in progress has ended normally
 bit 2=1, End of transmission
 bit 1=0, Multiprocessor value in receive data is 0
 bit 0=0, Multiprocessor value in transmit data is 0


SCI3 SDCR,FFFFF01E = 000000F2 = 1111 0010 = LSB first order, other bits not used




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 12
Date:

The baud rate is 7812.5.

B = 20 * 10^6 / (64 * 2^-1 * (N + 1)) = 2 * 10^7 / (64 * 0.5 * 80) = 7812.5



__________________


Guru

Status: Offline
Posts: 2338
Date:

motty wrote:

The baud rate is 7812.5.

B = 20 * 10^6 / (64 * 2^-1 * (N + 1)) = 2 * 10^7 / (64 * 0.5 * 80) = 7812.5



Excellent, many thanks ! Just out of curiosity - you used 80dec instead of 79dec ?

When typed 7911 in I am getting consistent readings using an USB RS232 module that accepts non standard bit rates. Now can proceed to trying out to build the ECU error codes into ECU Editor sw. The problem is now that the bits are coming as a burst of 8 bits, so need to find out how to handle that.

Additionally maybe the SCI1 can be reprogrammed to be used instead of SCI3 for receiving data - so that we can monitor the ecu online.

Also I should try continue finding BRR so that I could try out if the gauge could accept more standard rates for communicating with a std pc...



-- Edited by PetriK at 16:09, 2008-02-14

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 12
Date:

The "+ 1" is intentional. In the formula that you posted there is a "- 1" at the end. When you rearange the equation for B instead of N then you will have "N + 1".

__________________


Guru

Status: Offline
Posts: 2338
Date:

motty wrote:

The "+ 1" is intentional. In the formula that you posted there is a "- 1" at the end. When you rearange the equation for B instead of N then you will have "N + 1".




Yes or course smile.gif). It was 25 years ago when studied maths in university as major, now almost feels like have not used my brains since...



-- Edited by PetriK at 16:16, 2008-02-14

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 964
Date:



Also I should try continue finding BRR so that I could try out if the gauge could accept more standard rates for communicating with a std pc...
Most bit rate clocks in the end just divide the system clock by some power of 2 which means there is no number for a even clock like 10MHz that will give you 9600bps Ever wonder why you see some systems with odd crystal numbers like 4.9152MHz? Its because that number will divide evenly into standard baud rates.

You should be able to get pretty close however and most modern UARTs are pretty forgiving. They actually divide each bit into 32 parts and measure the the next bit 16 parts from the detected edge of the previous bit so they are always resynchronizing the bit edge. You should be able to be off by several 100




__________________


Guru

Status: Offline
Posts: 2338
Date:

OK - so the first test could be to hardwire the sh7052 RXD1 and RXD3 pins together and use the existing programming data route to test the ECU functions.

Have not been able to trace the RXD3 path from harness connector - if it exists. RXD3 pin is connected for sure - comes from IC102 - but then dont know anymore. Of course the PFC could set it to PB9, but in firmare the RXD3 interrupt exists and has active code.

The IC102 is something marked as ?704F, 8 pins, Pins 4,8 Vcc & Gnd. The sh7052 RXD3 is connected to IC102 pin2, i.e. it should be somekind of output.



-- Edited by PetriK at 16:45, 2008-02-15

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

I have a few trace diagrams i have worked up from a 04 ECU i will get them off my laptop and see where it goes i may even have a datasheet on the ic102 (7w04f) let me look.

__________________


Guru

Status: Offline
Posts: 2338
Date:

That would be excellent, dont really understand the serial protocol of the ECU at all.

The TXD3 is quite straight forward signal from TXD3 through couple of transistors to the TECH pin of the harness conenctor. During the tracing I noticed that the RXD3 gets the TXD3 signal echoed back by the circuits on the board.

The route back seems to be R957, D951, IC955, IC102 (inverter).

So either something is missed on the RXD tracing back or all this makes me to think that the TECH pin is bidirectional and that the queries about the data should be made in between the gauge cluster signal puses ?

Here you are with a link to the PCB with signal points marked:
http://www.bikeland.info/petrik/images/sci3trace.jpg


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

Yeah when i when i through the circuit i found the same thing but i looks like to me that 4 pins on the cpu are used for tanfering the data through the circuit the it goes out the header through the Tech pin to the dash.

Here is the diagram pic it may not be big enough i can email you them along with the datasheet for the inverter if you like.



__________________


Veteran Member

Status: Offline
Posts: 75
Date:

Pins PD8 ,PD9,PA1, and one more are used in the circuit.

__________________


Veteran Member

Status: Offline
Posts: 75
Date:

I also sent you a email containing the files open the diagram with a picture viewer and the pdf for the inverter.

__________________


Veteran Member

Status: Offline
Posts: 75
Date:

You cant see it in the diagram but the base of T951 (PNP tansistor) goes to pin PD8 on the CPU i believe it is Q3 on the diagram i forgot to renumber it.

__________________


Guru

Status: Offline
Posts: 2338
Date:

gsxturbo wrote:

You cant see it in the diagram but the base of T951 (PNP tansistor) goes to pin PD8 on the CPU i believe it is Q3 on the diagram i forgot to renumber it.



Excellent, many thanks !

A question: Can you confirm T951 really goes to PD 8 - or is it possible that its PB 8 ?

sh7052 (104) = PB9 = RXD3
sh7052 (103) = PB8 = TXD3

If the above is correct, then the schematic confirms that the IC102 is inverter and therefore can not switch the RXD signal to an another input. According to the schematic the IC955 (marked as SOT-23-5) is not connected to anything external either so that can not connect the RXD to another input. So the only conclusion is that the SIO protocol uses a single harness line for input and output?

About Q4? That looks like going to TIOB, ie. being part of the crank&cam pulse generation.

By measuring the IC102 with scope I get:
Pin 1 - Campulse
Pin 2 - Dash data
Pin 3 -
Pin 4 - Gnd
Pin 5 -
Pin 6 - Dash Data
Pin 7 - Campulse
Pin 8 - Vcc

(Campulse with slight reservation - most likely it is that, measured with scope that it varies by RPM, same idle duration and recall vaguely tracing it to this chip.)

I am a bit surprised how that is connected on the schematic...


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Some progress on hacking the gauge cluster protocol...

Initially when trying to push TTL level data to the harness connector 3 did not seem to initiate the RXI3 as all the key variables remained 0 (zero, nill, nothing). Anyway after some trial and error it looks like if a TTL level signal during the boot is sent continuously the ecu does not turn on the normal data stream to the gauge cluster and the RXI3 start setting variables that are used inside the subroutine.








__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

PetriK wrote:

 

gsxturbo wrote:

You cant see it in the diagram but the base of T951 (PNP tansistor) goes to pin PD8 on the CPU i believe it is Q3 on the diagram i forgot to renumber it.



Excellent, many thanks !

A question: Can you confirm T951 really goes to PD 8 - or is it possible that its PB 8 ?

sh7052 (104) = PB9 = RXD3
sh7052 (103) = PB8 = TXD3

If the above is correct, then the schematic confirms that the IC102 is inverter and therefore can not switch the RXD signal to an another input. According to the schematic the IC955 (marked as SOT-23-5) is not connected to anything external either so that can not connect the RXD to another input. So the only conclusion is that the SIO protocol uses a single harness line for input and output?

About Q4? That looks like going to TIOB, ie. being part of the crank&cam pulse generation.

By measuring the IC102 with scope I get:
Pin 1 - Campulse
Pin 2 - Dash data
Pin 3 -
Pin 4 - Gnd
Pin 5 -
Pin 6 - Dash Data
Pin 7 - Campulse
Pin 8 - Vcc

(Campulse with slight reservation - most likely it is that, measured with scope that it varies by RPM, same idle duration and recall vaguely tracing it to this chip.)

I am a bit surprised how that is connected on the schematic...

 



T951 is hooked to T952 (NPN ) then i goes to the 33ohm resistor then out the header. Q4 is T952. You are right about it going to
PB8.  Keep up the good work i would really likt to know how the data works on the dash exspecially the coolant temp part.

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Coolant sensor data is hacked. Originally by RR and now also confirmed as part of this testing:

The gauge data stream is 8bytes, first byte is coolant temp, last byte is checksum (sum of all and then negated). Appr these values apply on coolant temp:

Below 10 causes clt error / red light
Redline=10
1/2line=30
Coldline=100

I know that e.g. in gixxer the guys would like to have a new type gaugecluster in an old bike. I think that it would be very easy to program e.g. a PIC or any other type of small computer to send that kind of data.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:
Serial protocol works for monitoring the RAM variables


OK - it is possible to monitor the ram variables using harness connector instead of AUD connector, so the serial gauge & monitorin protocol of 32bit busa ecu can be said now hacked. Its like described previously on this board (0x13, bytecount, ramvar, checksum).

The interface is also as described earlier in this thread: Connect the RS232-TTL interface both RX&TX pins to the Black/Green gauge cluster data wire. That wire is bidirectional and through that the ECU can take in commands that will return the RAM variable in question back to the program.

As an example check out the latest build of the ecueditor program and press datastream. Select your com port and press Data ON. After that press reset on your ecu and you can monitor the RPM variable. TPS, IAP etc. can be added when I have time (including the nice feature of seeing which map is currently being used and for what value. Most likely with EU ecus and Oxy sensor its possible to generate preliminary fuelmaps just using the RAM variables and existing narrow band oxy sensor.)

http://macmadigan.no-ip.com/Public/ECU/ecueditor

If there are persons on this board capable of developing visual basic 2005 programs I would be interested in setting up a joint development effort/sourceforge approach. I am not a programmer really..., but have not found any ready made programs which this kind of functionality can be added.

-- Edited by PetriK at 17:40, 2008-02-16

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:
RE: SCI3 bitrate for diagnostics info


PetriK wrote:

Coolant sensor data is hacked. Originally by RR and now also confirmed as part of this testing:

The gauge data stream is 8bytes, first byte is coolant temp, last byte is checksum (sum of all and then negated). Appr these values apply on coolant temp:

Below 10 causes clt error / red light
Redline=10
1/2line=30
Coldline=100

I know that e.g. in gixxer the guys would like to have a new type gaugecluster in an old bike. I think that it would be very easy to program e.g. a PIC or any other type of small computer to send that kind of data.



Thanks a ton for that thats what i needed to know. Do the bytes go out throught the PD8 port on the cpu through the T951and T952 transistors to the header for the data?  Im using a Prallax processor to try and implement the coolant gauge to work so i think it should be pretty easy.

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yep - TTL level RS signal with baud date above...


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

To utilize this newly confirmed RAM variable tracing information, a proof of concept small software is put in here:

http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=15386188

May not work 100%, but you should get a good idea...

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Gsxturbo, just noticed while browsing the net for what purpose you need this info, very nice initiative.

Below is the code I am using for reading the gauge data. Bruteforce, but works. This should be very easy to reverse engineer.  This data should not be sent continously, rather with maybe around 50-500ms delays between bursts - have not measured exactly, but the gaugecluster seems to to be too fancy about how often it receives the string. For sending from PC to ECU I am currently using 250ms timer.

I have not checked if the gauge cluster needs other bytes too or is it ok to send those as zero. The second last byte is for fuel calculation basis. The ones in the middle are engine conditions. The Third from the beginning holds the TST switch information.  I have not hacked this to the bit flag information level, but will do most of that in the future.

Do you know where to get those ECU connectors you guys seem to have access ?


Dim tmp As Integer

bytecount = 0

TextBox1.Text = ""

Do While bytecount < 8

Try

  serialbyte(bytecount) = SerialPort1.ReadByte

  TextBox1.Text = TextBox1.Text & "." & serialbyte(bytecount)

  bytecount = bytecount + 1

Catch ex As System.TimeoutException

  TextBox1.Text = ex.Message & TextBox1.Text

  bytecount = 10

End Try

Loop


' calculate checksum

tmp = 0

bytecount = 0

Do While bytecount < 7

  tmp = tmp + serialbyte(bytecount)

  bytecount = bytecount + 1

  If tmp >= 256 Then

   tmp = tmp - 256

  End If

Loop


' show here the checksum and last byte which should match
tmp = 256 - tmp

TextBox1.Text = TextBox1.Text & " = " & Str(tmp)


If
tmp = serialbyte(7) Then

' build the data stream only if checksum matches

  temperature = serialbyte(0)

End If



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

Sorry for the late response my electric has been out all day seems a transformer blew up down the road and i was left in the dark.LOL

Yes i am working on a standalone ECU for the busa thats pretty cheap to get started in for the turbo guys.

Fantastic on the snip it of code you put up i havent even started to work on the SX processors for this yet but this will make my life a little easier im not the most code savvy there is is so it will probably take me months to get it to work but this will help out greatly with what im doing.LOL

Which connectors do you need the header or the harness connectors the harness connectors will be a tough one i havent found any supplier thats has them in stock so ordering them would mean probably a minimum of 500 but if enough people wanted to go in on them im sure something could be setup to buy them and distribute them to the people involved. Now if you need the ECU header i can get those for you fairly easily.

If you need the harness connectors i can try to call them this week and see on a price and the minimum order quantity for them if you want.

Thanks for the help with this, this is one of the main things i would really like to get working for my board.

__________________


Guru

Status: Offline
Posts: 2338
Date:

For this project we actually need only the individual pins for the harness connector as we need to add few of those. If you  know a supplier I would be very interested.

For my personal needs I would be interested for just the header connectors. I initially thought to use the ones from a damaged ecu - but looks like there may be an alternative. The purpose is to build a device for personal use that goes between ecu and the harness.

Electricity is a funny thing - I was just yesterday looking a document about Enron and California electricity laws. That was very educative.

I will propably write the code for sending the gauge data over the coming few days just to test an idea... so will publish it here when done.

-- Edited by PetriK at 13:06, 2008-02-18

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

In the other thread i posted some pins from the same manufacturer that fit directly into the connector and lock works great i have about 120 with wire if you want i could send you some. How many do you need?


__________________


Guru

Status: Offline
Posts: 2338
Date:

Have promised to build a couple of interfaces for my friends over here - getting pins will make that process easy to install which seems to be appreciated. Not many want to cut their wires but adding few is not a problem. Each interface requires md1+rct+fwe+txd+rxd so can easily use 25 or even more (5 x 5 for 5 interface units), will pm you.

Below is the code for sending gauge data, this sample sets the RED temperature light on but still displays the clock. Very simple piece of code.

Tested if the gauge data can exist simultaneously when reading the data from ecu. Unfortunately can not do that, at least easily. But as there is no temp gauge on bike it may overheat,  so if temperature gets too high I just stop reading the ecu data and turn the red temp light on.

Private Sub sendgaugedata()

  Dim b(10) As Byte

  Dim i As Integer

  Dim c As Integer

  Dim l As Integer


  c = 0

  i = 0

  b(0) = 5 ' CLT appr below 10 sets red light on, midline appr 30

  b(1) = 128 ' this clears the clock to visible

  b(2) = 0

  b(3) = 0

  b(4) = 0

  b(5) = 0

  b(6) = 0

  b(7) = 0


  ' calculate checksum
  l = 8 ' note this is L i.e. lenght, not value 1(one)

  i = 0

  Do While i < (l - 1)

    c = b(i) + c

    If c > 256 Then c = c - 256

    i = i + 1

  Loop


' the checksum is calculated using integer, here converted to byte, ie. 256=0
' this is the last byte to be sent
If
c <> 0 Then

  b(l - 1) = 256 - c

Else

  b(l - 1) = 0

End If


  SerialPort1.Write(b, 0, l) 'write L bytes from beginng to serial line

End Sub


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

Man your giving me all kinds of stuff to try out. As soon as my headers come in i will have to try this stuff out and see if i can get this thing working or not.

__________________


Veteran Member

Status: Offline
Posts: 75
Date:

So if i make up a program that will send out some data at say 250ms intervals with the gauge data it doesnt necessarily need to be in the 7812 baud rate? (forgive me if this is a stupid question i just started with the whole programming thing in the last few months)

If so i could just setup a Gauge Data map and temp sensor map inside the program and have it look at one of the inputs of the processor for feed back from my temp sensor and depending on what the temp sensor was reading it would look at the gauge data map,and temp sensor map then send the data to the cluster right?

The temp gauge is the one thing im most concerned about not so much the clock but if i could get both working that would be great.

__________________


Guru

Status: Offline
Posts: 2338
Date:

7812:8,n,1 is the one I am using - no framing errors or anything, data sycnronizes really nicely.

Tested 9600 and 4800 from PC to Gauge and those did seem to not work.

You just send those 8 bytes out with around 200-500ms intervals and thats it. FIrst byte b(0) is CLT information, by putting 128 to second byte b(1) you get your clock on, no "check" markings and last byte b(7) is checksum. Sum off all bytes negated.

The purposes of the checksum is that when that is added to all the other bytes the result should be zero when using bytes, not integers. All bytes are assumed to roll over zer i.e. ...253,254,255,0,1,2,3... . Therefore I decided to deduct 256 when the sum was more than 256. In VB if I use byte I get an error if I exceed &HFF (255) it does not roll over to the next numer.



-- Edited by PetriK at 08:56, 2008-02-19

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

Ok i see what your saying now basically this.

Set the Baud rate to 7812 for serial coms
then send out the bits (8) at 200-500ms intervals between bits then start over when the the bytes reach 255 you roll it back to 0 .

I will talk to you more about this through email if you dont mind i dont want to fill up this thread with elementrey programing questions.LOL

Now i need to find out how to get the SX to send out that uncommon baud rate any sugestions on that one?

__________________


Guru

Status: Offline
Posts: 2338
Date:

Its even more simplier:
1) Open the com port with these settings 7812:8,n,1
1) Set timer to tick at around every 250ms
2) At every 250ms tick, send all the 8 bytes
3) Close the com port

I dont mind answering publiclty. That the others may find the answers later and make things easier.

When I started this project about 6mths ago I had not seen sh7052 assembler, never done disassembling alone just have read commented code. Not used Renesas C-compliler, did not know what MD1,MD0 meant etc. Last ecu hacking project is years - so things had certainly changed.

Luckily RR had written some info and helped over here to get us going. We all should continue that open policy because someone will read this thread for busa k8 and think - hmm, i could test if this works for me too...




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

I see so you send the whole 8 bit packet at once every 250ms.

Ok sounds good to me like i said im REAL new to the whole programing thing i can program these things in both basic and assembly Basic seems to be the easiest for me to understand.

I posted a question over on the Parallax forums about the baud rate im using a 4mhz resonator on the chip right now but i can put anything up to a 50mhz on there so if its doable by just changing out the resonator and specifying it in code then thats easy enough.

I also had a look at my temperature file for a GM temp sensor for the ECU i use and it showed the ADC value for a given temp and it may be how they did the scale for the gauge

for a ADC of 10 i get 244deg F or 118degC

                   30 i get 179degF or 82degC

                 100 i get 105degF or 40degC

Now this is for a GM sensor but it could be how they did it that the numbers for the gauge represent the raw ADC value that the temp sensor reads at different temps (depending on the biased resistor on the board and the sensor it self).


-- Edited by gsxturbo at 10:16, 2008-02-19

__________________


Veteran Member

Status: Offline
Posts: 75
Date:

How close does it have to be to 7812 to work do you know ?

__________________


Guru

Status: Offline
Posts: 2338
Date:

Like said earlier in the thread few 100 maybe.

I recall using ECU with +100 (7911) and that still working, but that depends obviously on what kind of UART you have. With the current USB module I have no clue how exactly that sets the baurdate.

The ADC conversion values do look quite right based on first impression. Anyhow as the gauge data is not really very accurate, its most important to set the redline and midline correctly and to understand that below 10 you get the red indicator light on.

I dont know propeller very well, but bozo from this board seems to know. You could try to contact him ?


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

Thanks Petri my post over on the parallax forum got answered they said with the 4mhz xtal that the SX will be able to trasmit at  that Buad rate with no problems thay gave me a few sample programs to use.

They even said if i want to transmit and recieve on the same line that it would be no problem and gave ma a sample code for that but i dont think i need that.

So now i need to set up my gauge cluster and one of the SX's and start testing out some code and see if i can send the data to it .

__________________


Guru

Status: Offline
Posts: 2338
Date:

Could you please post a link to the propeller forum and the thread where you got these hints.

I am very interested about propeller and this seems like a good opportunity to learn more.

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 75
Date:

I actually use the SX28 processor the propeller is a little more advanced than what i need the SX series will do tons of stuff i use the 28 pin SMT version. Here is the link for the thread where i ask about the baud rate.

http://forums.parallax.com/forums/default.aspx?f=7&m=251099

You can download the code that Jonnymac posted and open them in word pad to view them all the books and the SXkey IDE compiler is free for download at the Parallax website I use the same processor for my autoshift and auto kill feature on my interface board.

I have two of them on my board and the extra one is the one i want to setup for the serial to dash stuff.

__________________


Veteran Member

Status: Offline
Posts: 75
Date:

You can buy a project board from Parallax with the SMT version of the SX28 and 5v power supply on board for &10.00 us all you would need is the SXKey around 50.00us (to program and debug the SX) and a wall wart and you could start playing around.


http://www.parallax.com/Store/Microcontrollers/SXTools/tabid/139/ProductID/494/List/0/Default.aspx?SortField=ProductName,ProductName

http://www.parallax.com/Store/Microcontrollers/BASICStampModules/tabid/134/ProductID/399/List/1/Default.aspx?SortField=ProductName,ProductName




-- Edited by gsxturbo at 07:46, 2008-02-20

__________________


Guru

Status: Offline
Posts: 964
Date:

gsxturbo wrote:


for a ADC of 10 i get 244deg F or 118degC

                   30 i get 179degF or 82degC

                 100 i get 105degF or 40degC

Now this is for a GM sensor but it could be how they did it that the numbers for the gauge represent the raw ADC value that the temp sensor reads at different temps (depending on the biased resistor on the board and the sensor it self).




This may have already been covered elsewhere but...

The Analog voltage of the Engine Coolant Temp (ECT) sensor is used as the input to a conversion table or 2D 'map' that converts the non-linear voltage into degrees C. This value is then sent to the Dash.  To convert the data byte sent to degrees C use

Degrees C = ((data/16)-3)*10

or I guess more useful would be

data = ((C / 10)+3)*16

So to send a temperature of 20 degrees C to the dash you would send a byte of 80 decimal.

BTW the inlet air temp uses the same conversion formula

 



__________________


Veteran Member

Status: Offline
Posts: 75
Date:

RidgeRacer wrote:

 

gsxturbo wrote:


for a ADC of 10 i get 244deg F or 118degC

30 i get 179degF or 82degC

100 i get 105degF or 40degC

Now this is for a GM sensor but it could be how they did it that the numbers for the gauge represent the raw ADC value that the temp sensor reads at different temps (depending on the biased resistor on the board and the sensor it self).




This may have already been covered elsewhere but...

The Analog voltage of the Engine Coolant Temp (ECT) sensor is used as the input to a conversion table or 2D 'map' that converts the non-linear voltage into degrees C. This value is then sent to the Dash. To convert the data byte sent to degrees C use

Degrees C = ((data/16)-3)*10

or I guess more useful would be

data = ((C / 10)+3)*16

So to send a temperature of 20 degrees C to the dash you would send a byte of 80 decimal.

BTW the inlet air temp uses the same conversion formula

 

 




 Thanks to Petri  i got the dash sorted out last year i have contiually worked on my program to where im at now, it works really good so far, the temp gauge has a tiny amount of huntting in certain spots, but overall it works really good, it took me a while to figure out the correct way to send the data , and calculate the data to be sent ,but it works wonderfull so far .


 

 



__________________
Page 1 of 1  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard