Sensors with LIN Bus interface

[Zlotnik]

Hi all,

I’m interested in tracking temperature and humidity in several areas in my car, and am researching sensor and bus alternatives for the sensor network. I’d like to make each sensor node as simple, small and cheap as possible, and I’m looking at harness lengths of 5m-10m or so max.

For this application, LIN bus seems perfect - no wonder, this is exactly what it was developed for. However while there’s a plethora of easy to use temperature and humidity sensors with digital outputs over I2C or 1-Wire, it seems very difficult to find similar products with LIN output.

Of course I could use an analog or I2C sensor, an ATtiny and a LIN transceiver, but that is a lot more complexity in the sensor nodes than I wanted. I’m not so confident in using I2C directly over this length in an automotive environment over 10m. 1-Wire could be an option, but I don’t have experience with that. Is that robust enough for an automotive environment?

Do simple temperature and humidity sensors with LIN bus interface not exist? I have the feeling I’m missing something obvious.
I’d be curious if anyone here knows of temperature and humidity sensors with integrated LIN bus output, and where I could find them.

[miceuz]

LIN adds a lot of complexity itself, especially the need to maintain ping/response in timely fashion. It's useful when LIN slave is an actuator of some kind, especially the one that could cause injury, but for sensors I think this is an overkill.

Modbus over RS458 is a bit more relaxed I think. Have a look at this board I have designed: https://github.com/Miceuz/rs485-breakout it's both hardware and Modbus firmware ready to go. You can order PCB or you can get one assembled from my Tindie store: https://www.tindie.com/products/miceuz/rs485modbus-dev-board/

[Zlotnik]

Hm.
The response time for the LIN slave is of the order of ms, no? That’s not terribly stringent imho. Plus, it’s the slave that needs to comply with reply times, so if there’s sensors with LIN bus output, they should take care of that.

Modbus being a high level protocol is actually more complex than I was thinking. Instead of the RS485 + modbus route, I could also just use a differential i2c driver like a P82B96, and talk to i2c sensors directly as well.

Still: LIN sounds like it’s engineered for exactly the type of automotive application I’m thinking of, I’m surprised to find almost no temp & humidity sensors that speak it. I’d think every modern car has a bunch of them for climate control. Am I looking in the wrong corners or using the wrong search terms?

(PS: Nice project on GitHub and Tindie though!)

[miceuz]

Yeah, I have checked docs of my old LIN project - the stringent requirements were imposed by a particular actuator I was controlling via LIN, not the protocol itself.

Being experienced with both LIN and Modbus I still would choose Modbus just because the code I have for it is more mature, but that's just me I guess 

[SparkyFX]

I’d like to make each sensor node as simple, small and cheap as possible, and I’m looking at harness lengths of 5m-10m or so max.[...]
For this application, LIN bus seems perfect - no wonder, this is exactly what it was developed for.

Nope, LIN is perfect for heterogenous environments (1 type of node per subnet), not homogenous (many times the same type of node on a subnet) as you describe. But as the master/primary has to poll from all nodes within time you will need to come up with a way to set addresses on each node and reflect them in the message. That runs into limitations quite fast, so you basically have to develop your own node controller (and therefore your own data dictionary). Surely not cheap and simple.

1-Wire is better suited as every node already has a unique ID from the factory to adress it, which is reflected in the protocol, electrical characteristics can be kept under control by bus extenders.

[Zlotnik]

Hm, not sure I completely understand the heterogeneous vs homogeneous LIN bus issue. The master will have to poll each node it's interested in, and only the slave whose ID was addressed in the header is permitted to respond, right? To keep it simple, I would simply poll only unconditional frames, there's no need for high update rates in this application.

Or do you mean all pre-programmed nodes of a specific type will share the same address? I have to admit I assumed the ID of the nodes would be configurable statically, eg by jumpers. Of course, since I didn't find suitable sensor nodes, I haven't checked datasheets...

For the 1-Wire idea: how well suited is 1-Wire over moderate lengths in a noisy environment? If it's robust enough that I can get by without differential lines eg with a DS2484, the simplicity of the harness is appealing over the I2C P82B96 route.

[max_torque]

LIN bus allows you to "save" 1 physical wire.  Hardly a worthwile save in a make a few of them type situation.   And given that LIN is ultimately going to be driven by some form of USART ie needs a micro, then just use that same micro's USART to drive a polled RS-485 bus.  The Transcievers are even cheaper, the parts count pretty much identical, and you'll find many many more off the shelf devices that use it (all the industrial stuff)

MODBUS is a trivally small amount of extra software to implement, or you could just define your own packets and slave IDs and do your own thing.  Or make your custom slaves ignore the ModBus commands and you can use BOTH your custom protocol and the modbus one!

LIN is broadly designed for very low bandwidth control type coms, ie not really for sending any significant amount of data around, and it's totally optimised to be minimal cost when you are making MILLIONS of the devices, which is totally insignificant if you are make tens or hundreds of devices...

[SparkyFX]

Or do you mean all pre-programmed nodes of a specific type will share the same address? I have to admit I assumed the ID of the nodes would be configurable statically, eg by jumpers. Of course, since I didn't find suitable sensor nodes, I haven't checked datasheets...

So is my understanding of LIN, but better check the datasheets.