Jump to content

X-Like


Anderzander

Recommended Posts

http://www.ebay.co.uk/sch/i.html?_odkw=defender+binacle&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR2.TRC1.A0.H0.Xrange+rover+height+sensor.TRS0&_nkw=range+rover+height+sensor&_sacat=0

They are all basically the same - a very high quality, very linear, plastic track 10k pot with the 3 connections brought out. Wire as a potential divider and you have a voltage proportional to sensor position.

Though they are expensive on eBay - at places like Newbury Sortout they are almost free!

I've used them many times (though rarely as an axle height sensor).

Si

Link to comment
Share on other sites

Ahh, thanks Si, heights sensor used for steering angle instead...

... one way that steering angle sensors work is an encoder principle using two magnets, gear driven (odd count of teeth between them), .... easier to have a look at this... page 12 https://www.infineon.com/dgdl/Infineon-Sensor+Solutions+for+Automotive,+Industrial+and+Consumer+Applications-SG-v01_00-EN.pdf?fileId=5546d4624cb7f111014d4811f9926ebd

it's actually not that complicated if you can butcher an existing steering angle sensor... I've got one from a Seat that I'm hoping to re-appropriate (it has a canbus output but you would have to decode... I was just going to replace the PCB given infineon were giving out free samples a while a go and I managed to pick up what I wanted... (always worth a check on prototype work...)

rob

Link to comment
Share on other sites

2015 Defenders have one on the steering column for the DSC I think.

Right! .... part number required (anyone got the latest parts book avail or should I ask over in parts no requests :ph34r: .... didn't know they had DSC on a fender now... (mind you they all do... its called a right foot release & centre pedal apply manoeuvre, with coordinated steering wheel flick ... wich change of underwear :banned: )

Link to comment
Share on other sites

Reading a voltage is a lot easier than quadrature / CAN! (and only uses one pin on your microcontroller!)

Si

Yes I agree but if the chip does all the work for you already and provides two bits of info at once (angle plus angular velociy) without microcontroller load simply putting it on the canbus it cant be that bad

Yes I'll admit the thought of using a height sensor never crossed my mind so yes that would be easier but things like sensor longevity (rheostat moving back and forth cant be good over time), mechanical damage (hanging under the vehicle subjected to potential offroad damage plus water and saltspray corrosion) and also accuracy (more than likely you won't be getting near full travel of the pot) also need to be considered relative to the application accuracy required

(I'll admit I was a little more interested in steering angle than wheels pointing direction as I was interested in how adaptive breaking or torque vectoring could be implemented (curiosity more than application before someone says something (no harm in logging sensors))

Rob

Link to comment
Share on other sites

Right! .... part number required (anyone got the latest parts book avail or should I ask over in parts no requests :ph34r: .... didn't know they had DSC on a fender now... (mind you they all do... its called a right foot release & centre pedal apply manoeuvre, with coordinated steering wheel flick ... wich change of underwear :banned: )

nothing in the steering column parts list for any 'wiggly amp/sparky' bits http://new.lrcat.com/#!/1235/5925/6048/528

there's a Yaw sensor on cab side of bulkhead shown in http://new.lrcat.com/#!/1235/2632/3020/232

not sure if that does the job your all talking about.

Link to comment
Share on other sites

cheers Western... yes in part they use a yawl sensor to detect slide, but the steering wheel position sensor is usually used to confirm the direction that the driver was intending to go (i don't believe that it's quite essential but beneficial...).

If yawl is detected if will probably confirm it with the wheel sensors, and then break the inside rear (understeer) or outside front (oversteer).

(but I'm no expert just a curious car enthusiast...)

https://www.youtube.com/watch?v=DyeJmY9c47w

would have thought that it would have been "easier" to work out the intended direction from a steering angle sensor than calculating the difference in wheel travel, but then it does need to be able to do it on and off road where terrain is not level or equal on both sides of the vehicle.

Rob

Link to comment
Share on other sites

that's the one.... at least its designed for operation under water when the rooflight (muppet! sunroof), windscreen or bulkhead leaks.... :rofl:

cheers western (if I'd had a thumbs up symbol I'd have used it)

Gulp, £100... (i won't be fiddling with that anytime soon...)

Does this mean that the TDCi's are Canbus....?

Rob

Link to comment
Share on other sites

Hi Simon,

Following with interest. This guy is making a lot of headway interfacing LS1 canbus with BMW canbus.

He also interfaced to a D2 at one point.

http://www.bimmerforums.com/forum/showthread.php?1887229-E46-Can-bus-project

Commoditising the hardware to do this is, is a real opportunity to my mind.

Heaps of Petrol D2 crying out for a re engine in the states and Oz.

RR

Ooh :wub: I'm going to go through that thread with great interest!

If you're thinking of tagging the gauges onto the canbus network

I wouldn't do that, I was more thinking a separate network for the gauges and sensors. This also means you don't have any issues with overlapping IDs and such. As Si said, any info you could want from the car for a gauge is probably on OBD. And if it isn't, nothing's stopping someone from making a bridging module that reads messages from one CANbus and sends it out on the other one ;)

Link to comment
Share on other sites

Si, do you use through hole or SMT? If SMT what do you use to solder + how difficult is it?

I recently obtained a 1430 pack of 73 assorted 1/4w resistors £6 from china, £10 uk stock, given it works out loads cheaper than how I was buying resistors in bulk single value packs. I've also obtained packs of ceramics, electrolytics and trim pots the same way, may be useful to someone interested in doing development work. component availability seems to have improved since I started dabbling a few years ago (hence decided to get my setup sorted with assortment trays etc, given I spend half my time scratching around for passives or a single item component).

Elbekko, with regards to the shared use of canbus.... I may be wrong here (open to guidance from someone in the know), but you should not have a problem if you use low priority messages.... (sorry not sure if this is of benefit to anyone, or i should have started a new thread in the fab section). suggest a read of this may be of use if anyone is interested. http://www.ti.com/lit/an/sloa101a/sloa101a.pdf.

For anyone interested and to try to explain it in simple terms, if a node (device) is talking on the bus, all other devices wait until it's finished talking, presuming that there are a few nodes all waiting to transmit data, at the end of the message, they all wait a standard set time following the transmission of the last bit (presuming the last message was sent successfully, all nodes (devices) that have something to say will start outputting bits in sequence, and will listen to the network to see if there message has priority. This is done, by outputing a "Start of Frame" (SOF) bit [basically a "1"] and it allows all devices to synchronise (given they all output it together, next comes what is called the 11 bit identifier (basically space for 11 ones or zeros to be output onto the bus [no comments about zeros please yet), which means that if there are three messages and one has an identifier of eleven "1's" in a row, it is the most important message because as the other devices output there messages and listen to the network, one node / device that has a message with say three 1's followed by 8 pauses (zero's) will outputs its three "1's" in a row whilst listening to the network at the same time will figure out in the space for the 4th "1" where it is trying to leave a gap in the network (essentially a zero) that it's message is not high enough priority because another device with a "1" has output something, hence it will then keep quiet and wait for the other device to continue outputting "1's" and leaving spaces in the network sequence (clock cycle), and try again to send it's message at the end of the current one that had a higher priority. .... now I've confused you... :blink:

The chances of two devices outputing the same "low priority" messages at the same time (say bitwise less than decimal 15 (b1111) or decimal 7 (b111) must be fairly remote... to an 11 of 29 bit identifier [called the arbitration field])

The other thing that is really good with canbus is the payload ... how much data a single message can carry which is up to 8 bytes of data (basically if you were to send an engine temperature reading you would use something like 1 byte of information (hence you still have 7 bytes free for other data), which means the same message could contain engine oil pressure (1 byte), air inlet pressure (1 byte), etc etc.

Hence if you have a look at the link I posted earlier, the way that J1939 works is node (device) would output many different messages but they would all be given different standard references which inform what the payload of the message is [think if it as an index number] (called a "PGN"), when a message is output it can be read by many controllers (actually they all read them, but decide whether they are relevant to their function). hence a PGN actually contains many spn's (which is the actual bits of information in a certain sequence), so if a controller receives a PGN65263 message it knows that byte 4 of that message contains the oil pressure and byte 1 of that same message contains the fuel pressure.

A canbus message could be 45 bits in length minimum (or there abouts if you're actually not sending any data [think of it as a "I'm alive message maybe") up to ~ 114 bits [or 134 bits in extended identifier format].... and the bus could be running at up to 1 million bits per second, but normally 250 thousand bits per second (J1939) [GMlan is suppose to be 500kbs] .... hence you're unlikely to much load on the canbus network with a few low priority messages at reasonable polling frequency, plus it will allow you to carry out ODBII PID enquiries / calls at the same time.

you'll notice that J1939 is extended message format, which means that you could probably send low priority messages using extended identifier format and they would never be noticed and affect traffic. You can send standard and extended identifier messages on the same network too. http://www.kvaser.com/software/7330130980914/V1/can2spec.pdf

There is probably holes in my reasoning, but you can do your own research and reach your own conclusion (should be enough reference material there for a start at canbus hacks..., or what could be considered as a reasonable resolution transmission of sensor data (do you need 16 bit when 8 bit will do, considering resolution per bit + offset (such as SPN106-Intake Air Pressure - 2kPa (absolute)/bit, zero offset, 1 byte data length).

Rob :popcorn-and-drink-smiley-emotic

Link to comment
Share on other sites

This evening has been a bit of a slog finding a library that will talk to the OLED display. Finally i have a simple program that displays a few screens of characters & graphics. I'm blown away with the quality of the image. The photo doesn't do it any justice - my phone does not want to focus on the display. Ill maybe have a go with a real camera tomorrow.

post-74-0-49611500-1435611060_thumb.jpg

It's readable even in bright conditions because the contrast ratio is so high.

I have it hooked up to a CAN Board so I'll see what I can read off my RRS then have a crack at the Td5. Td5 is not so easy because it does not conform to the standard in particular communicating at 9600 rather than 10800 bits per sec which is why most scanners will not read it.

Anderzander - thank you for the offer, but I have my own!

Si

Link to comment
Share on other sites

Thanks for the info Rob, I get that it *shouldn't* be a problem, but I'd prefer avoiding sending stuff on a vehicle's CANbus without fully understanding what the side effects could be. Especially if you want to support multiple vehicles. As far as I understand it, you always have to have a device ID, which tells the other devices what the message is about. You never know that your temperature sensor has the same ID as the brake light switch on a Suzuki, and things start going haywire...

Si, that display looks very good indeed!

Link to comment
Share on other sites

This evening has been a bit of a slog finding a library that will talk to the OLED display.

Si if you want a hand with the code / electronics side of things more than happy to give you a helping hand. Perhaps in exchange for my, probably bonkers, idea of a concealed winch mount for an L322...

I don't know what era your RRS is from but I have a 2007 TDV8 L322 if you want to try it out on more vehicles.

Link to comment
Share on other sites

Shared canbus, yup l hear you, but you've got to be very unlucky to choose a shared arbitration message address given how many they potentially are... And it is suppose to be open source so you could readdress at will

The problem with two busses that Simon will have if wanting to use a multiplexer will be pins and ports for a second serial port on his guage microprocessor...

I guess you could buy two gauges.... One for obd2 pid information, and a second for the second bus to the multiplexer or for add-on modules...

Rob

Link to comment
Share on other sites

Shared canbus - unless you can be 100% certain it's fine you probably don't want the court case the 1st time someone has an accident and happened to have your gadget hanging on the same bus as their airbags & ABS. Fine for home tinkering but if you're going to sell them to Joe Public you've gotta think twice.

Link to comment
Share on other sites

Just for the record, I'm not going to use CAN at all - I'm using the ISO 9141 / ISO 14230 as more vehicles have K / L lines (K only in the case of Td5) than CAN, including Td5's (Though Td5 doesn't implement ISO 14230 properly, using 9600bps instead of 10400bps) but I'm hoping I can persuade the interface to accept it anyway.

Apparently it also has a non standard initialisation stiring - but I should be able to brute-force this.

I'm using an ELM327 OBD / Serial interpreter which just uses a simple AT Command set - including one to change the bit rate (fingers crossed!)

Because pin count is an issue, and the gauge is going to have WiFi for configuration, my plan is to use one of these http://www.ebay.co.uk/itm/WiFi-ELM327-Car-OBD2-OBDII-Diagnostic-Scanner-Scan-Tool-For-PC-iPhone-iPad-IPod-/231408998097?pt=LH_DefaultDomain_3&hash=item35e10d16d1 to connect to OBD if you have it, thereby using no additional pins.

It also means that it only requires one connector on the back of the gauge (probably a D9 or D15) to carry analogue signals from sensors + the relay connection(s).

I agree with Fridge that the risk/reward ratio is poor for sharing the CAN bus with the vehicle.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We use cookies to ensure you get the best experience. By using our website you agree to our Cookie Policy