Gav
|
| posted on 29/11/05 at 09:23 PM |
|
|
ahh no i think youve mixed it up a little
ie
MSComm1.Output = Hex(11)
this is wrong what your saying here is convert the decimal number 11 to hex then send it, however the number 11 is in hex anyway (DC1)
so 11 hex = 17 decimal
might be better if you create some constants so its easy to remeber what number means what
ie (if my VB memory is correct  )
Public Enum EdipCommands
DC1 = &H11
DC2 = &H12
End Enum
Public Enum EdipConstants
ESC = chr('#'
etc...
End Enum
it think the chr command returns the binary number for the character passed into it?
|
|
|
|
|
tks
|
| posted on 29/11/05 at 09:39 PM |
|
|
Ok
i think i have got it!
''Chr(6) ==> 06
''Chr(0) ==> 00
''Chr(17) ==> 11
the value after ==> is the value wich gives the port monitor..
sow now its just a question of sending!
we will see..
Tks
It works!
Finaly i recieve 06 (ACK)
pff what an job is this..
ok we are there.. now is MCU time...
[Edited on 29/11/05 by tks]
The above comments are always meant to be from the above persons perspective.
|
|
|
MikeRJ
|
| posted on 29/11/05 at 09:43 PM |
|
|
quote:
Originally posted by Gav
it think the chr command returns the binary number for the character passed into it?
The CHR() function returns a string with the the ASCII character of the number you put in it. e.g.
debug.Print CHR(31) would print '1'
The ASC() function returns the ASCII value of a character e.g.
debug.Print ASC("1" ) would print '31'
[Edited on 29/11/05 by MikeRJ]
|
|
|
Gav
|
| posted on 29/11/05 at 09:51 PM |
|
|
ah yeah thanks Mike, ASC() it is,
been a while since ive done vb 
|
|
|
tks
|
| posted on 29/11/05 at 09:56 PM |
|
|
already sended!
see post above
It works!
Finaly i recieve 06 (ACK)
pff what an job is this..
ok we are there.. now is MCU time...
Now i'm making the pic prog..
The above comments are always meant to be from the above persons perspective.
|
|
|
Gav
|
| posted on 29/11/05 at 10:01 PM |
|
|
id be interested if you wanted to share the details of the pic programming side as its something ive never done.
will you do doing it in C or assembler?
|
|
|
tks
|
| posted on 29/11/05 at 10:06 PM |
|
|
in basic!
I use an basic to assembler compiler for it.
It makes life allot easier!
i have learnd it all my self.
also the knowledge of the electronics asside of it.
in fact i studied Mechanicl Engineer for 4 years.
But i have always earned more money with Computers/Programming programs
and hobbied more with electronics..
look at my movi! from the electronic gearbox i made!
its in the other topic!
Tks
[Edited on 29/11/05 by tks]
The above comments are always meant to be from the above persons perspective.
|
|
|
tks
|
| posted on 30/11/05 at 12:03 AM |
|
|
MOD problem..
Can you explain to me this?
Clear display and draw a line from 0,0 to 239,127
<DC1> len ESC D L ESC G D 0 0 239 127 bcc >
$11 $0A $1B $44 $4C $1B $47 $44 $00 $00 $EF $7F $DA
$DA = bcc = 218 how did he calculate this?
i know the key factor is MOD 256
its 38 difference... is this an error in the PDF? page 8.
bcc= 1 byte = sum of all bytes including <DC1> and len, modulo 256
sow in my example 12 mod 256? ==>$EB
==> 235!
i did this: 256/12 = 21,xx 256-21 = 235
Tks
The above comments are always meant to be from the above persons perspective.
|
|
|
Gav
|
| posted on 30/11/05 at 09:23 AM |
|
|
The sum of the bytes is $2DA so the modulus division (remainder) of this will leave the $DA part.
$2DA / 256 = 2.852
so were interesed in the remainder part
presumable you can get the float part?
so
.852*256 = 218.11 so then just round this value to get the 218
|
|
|
tks
|
| posted on 30/11/05 at 11:17 PM |
|
|
COMPLICATED :o
How the hell i'm gonna make this working?
pff the sum of the bytes can you clear that part for me?
i want to send ESC D L BOND
i think i need to invent the ASCII mode it should be allot easier isn't it?
Tks
The above comments are always meant to be from the above persons perspective.
|
|
|
Gav
|
| posted on 30/11/05 at 11:32 PM |
|
|
The checksum is the sum(addition) of all the previous bytes ie
$11+$0A+$1B+$44+$4C+$1B+$47+$44+$00+$00 $EF+$7F = $2DA
so the checksum is $2DA mod 256 = $DA
from what i can gather ASCII mode still requires you to wrap your commands in the packet frame, which would include the checksum
|
|
|
tks
|
| posted on 30/11/05 at 11:59 PM |
|
|
mhh
but if that would be the case then the ASCII mode has no sense right?
because to calculate the bcc you will need to convert it to DEC values any way..
and if it would need HEX then it would only be an small step.....
The above comments are always meant to be from the above persons perspective.
|
|
|
tks
|
| posted on 1/12/05 at 12:14 AM |
|
|
how would you do the job?
i think the best thing i can do is make an module wichwill translate it
i want to send 1S to the module and he needs to make up the right $ order incl checksum!
one becomes crazy man with this stuff!
Tks
The above comments are always meant to be from the above persons perspective.
|
|
|
Gav
|
| posted on 1/12/05 at 09:20 AM |
|
|
How would i do it?
i would use the binary mode as its not hard and has more relevance to my experience.
If i have understood the macro stuff correctly i would create a macro for each screen then just update the values, ie speed, oil pressure etc by
drawing in the places where i want them to go
For the comms I would create a function that passed a block of bytes would generate the checksum. This function would then be used by other
functions to create specific outputs ie writing the speed to X,Y pixels on the screen.
if its help you figure it out i could create a visual basic module with some functions.
only problem is i wont be able to test it myself with the emulator
[Edited on 1/12/05 by Gav]
|
|
|
Gav
|
| posted on 1/12/05 at 09:39 AM |
|
|
I've actually been looking into leaning how to use PICs and electronics and i found this: http://www.picant.com/p2c/p.html
So i can still use pascal
|
|
|
tks
|
| posted on 1/12/05 at 07:59 PM |
|
|
Shots!
Look at the photo's and tell me your thoughts..
 
Rescued attachment SoonMore.JPG
The above comments are always meant to be from the above persons perspective.
|
|
|
tks
|
| posted on 2/12/05 at 08:39 PM |
|
|
ok!
The display is working!
The module board is off:
It has:
- Start you engine with an press button(like mercedes)/ renault laguna
- Onboard Temp sensor
- Onboard Eeprom for memory (256 Bytes-512bytes max.-)
- An Touch screen LCD for display and for setting things up....
What i now need is some math people from here....
I need to make the virtual temp curve!
How many readings do we need to log to make an good approx of the real engine temp?
Tks
The above comments are always meant to be from the above persons perspective.
|
|
|
Gav
|
| posted on 2/12/05 at 08:50 PM |
|
|
as in how many times you want to sample the temperature a second?
|
|
|
tks
|
| posted on 2/12/05 at 09:01 PM |
|
|
pff
once in an fiver?
the pic is really doing nothing sow an bit of work..
Its more that i want to build an open system.
Sow i will need to make something like this:
ADCVAL @ 20Degrees
ADCVAL @ 40 Degrees
ADCVAL @ 70 DEG
ADCVAL @ 90 DEG
ADCVAL @ 110 DEG
TEMPTYPE: NTC/PTC
Then with that.. in mind the pic will calculate an bit and interpolate...
and send the value to the display...
Will explain the working.
If you put the temp sensor in series to ground with another variable resistor.
Then between the 2 will vary the voltage because of the changing temp.
an ADC (ANALOG to DIGITAL converter) measures the voltage and compares it with the 5volts input voltage.
if it measures 5volts and its an 10Bit ADC it gives you 1024 as value.
sow if it measures 0volts it gives 0 as val.
sow we can measure up every 5/1024=0.005volts... enough i will say
how do i make the scale up?
The formula?
i can program for every zone his own formula no problemo..
Tks
[Edited on 2/12/05 by tks]
The above comments are always meant to be from the above persons perspective.
|
|
|
Gav
|
| posted on 2/12/05 at 09:48 PM |
|
|
So how are you going to deal with all the inputs(revs/fuel/temp/oil pressure)? some sort of multiplexor?
|
|
|
tks
|
| posted on 2/12/05 at 09:57 PM |
|
|
..
I can make the measurement as fast as i want because the cpu hasn't nothing to do really!
we talk about 20Mhz!5Mhz eff.
that's bloody fast..!!
Speed: 2Hz
Revs:8Hz
Fuel :0.2Hz
Temp:0.2Hz
Oilpress: 2Hz (i need an oil pressure sensor any one has one spare??)
Who wants to see this value as an daily driver? think in race mode i swap it for the fuel monitor!
Tks
The above comments are always meant to be from the above persons perspective.
|
|
|
Gav
|
| posted on 2/12/05 at 10:36 PM |
|
|
yes i understand that, however its the how do you get the signal into the PIC i dont.
ok lets say have 5 different data values you wish to read, how do you go about feeding that into the PIC?
|
|
|
tks
|
| posted on 2/12/05 at 10:59 PM |
|
|
tomoorow i will explain..
The above comments are always meant to be from the above persons perspective.
|
|
|
tks
|
| posted on 3/12/05 at 07:25 PM |
|
|
ok its today!
ok the signals aren't there!
you have to generate them!
the only thing an sensor does is giveing an pulse on an mcu pin.. we then know what that pulse means...
Example: Rpm.
We know that there are 2 rpm for every spark fired. (on an one coil per cilinder setup). Sow if we count the times
our MCU pin is pulled (low to ground)
like the coil and multiplicate this by 2 we have our Rpm!
Offcourse we do this by making an kind of Do Loop where in we check out RPM pin on its state if its low we inc the rpm
but we need to measure high before incing again the pic would easyly count one spark 5 times!
Basicly its all Digital communication
Counting Duration between to pulses
Speed:
Our prop have lets say 2 magnets.
We hook the sensor up that when the magnet comes near the sensor the sensor gives an voltage higher then 0,6..
ok, with that voltage we activate our Transistor wich activates our MCU pin.
He pulls it to ground...
Ok, we now can measure the time the prop takes between 2 highs!
lets say its half an second.
We then know that the prop turns once an second..
(60rpm/min)
We know the travel of the rearwheel when the prop turns once.
if whe multiplicate our propturns per hour
with the distance of the wheel per turn in mm we will get an km/h after dividing / 1000 000
its all an question of maths
Electronic components wich makes the signals beatiful for our pic..
(an pic doesn't work with Sinus crap!)
We only need adc (voltage to digital number) for position information.....
everything clear??
The TEMP on our display how much after the comma??
25.5deg
25.05deg?
25deg?
Regards,
Walter
The above comments are always meant to be from the above persons perspective.
|
|
|
MikeRJ
|
| posted on 4/12/05 at 03:19 PM |
|
|
You only need to display to the nearest 0.5 degrees C, any more and the display will be constantly changing.
Making a digital dashboard update frequently enough, but not too often as to become distracting is a crucial part of the design. You WILL need to
implement digital filtering on the analog values, even if it's only a simple averaging filiter, otherwise any noise on the inpts will cause the
displayed reading to vary. A traditional analog gauge moves very slowly so ignores electrical noise. If you want a simple low pass filter algorithm
I can help you with that.
As you are using a PIC, you may want to look at using the CPP module in capture mode for speed and RPM measurement. This makes the pulse measurements
very simple with very low CPU overhead (it means you can carry on updating other stuff while a speed measurement is being taken).
|
|
|
