The SENT protocol, standing for Single Edge Nibble Transmission, is used for sensors that need to send high-resolution data while keeping system costs low. It’s most typically used in the automotive world, where it can be found in such parts as throttle-by-wire pedals and temperature sensors. [Mark Smith] set out to see if he could get the Pi Zero to read such sensors without the use of an intermediate microcontroller.
[Mark]’s initial attempts relied on Python and the RPI.GPIO library. Unfortunately, the overheads introduced made decoding SENT traffic impossible. Undeterred, [Mark] pressed on, leveraging the pigpio library and its callback function which allowed sampling at up to one microsecond. This was fast enough to read the messages from a LX3302A inductive position sensor that uses the protocol.
It’s a project that could prove useful for those trying to work with certain sensors who want to avoid adding complexity to a Raspberry Pi project. Files are available on Github for the curious. We’ve seen other direct sensor builds with the Pi, before too – like this power monitoring system. Video after the break.
I think the article misses the point of SENT.
It is NOT low-cost! By far not. It’s expensive, and special, the interface on the controller side takes either up a lot of active time in the mcu, or a special peripheral. And the controllers with such an interface are the big ones.
But why is it like that? They wouldn’t create such a thing without need.
Timing! SENT sends always it’s own time base with each transmission, and is quite robust. Before the ISO26262 safety standard, it was one of the early implementations with safety in hindsight.
But even on a MCU it’s difficult to implement. And even more difficult on a microprocessor!
Features include a counter, so each frame can be checked for missing frames, also a crc to check against.
So you can see whether the sensor is still active, and functional.
Nothing a IO interrupt couldn’t handle easily without much CPU intervention.
This open a way to CNC for RPI
I thought SENT can pe imemented only using a timer. Freerun the timer and sample the counter when the edge changes, reset the timer. Based on the counter value you can decode one nibble. Sure, you need to read the sync pulse(the same way maybe) and compensate for the difference.
Was very excited when I thought you were talking about a SCENT sensor ;-). Still pretty cool though.
i’m mixed between outraged and enthralled that people would do something like this using off the shelf libraries in userland on a full-featured processor running unix. i don’t know the SENT protocol but generally these kinds of I/O problems are best handled by using all of the fancy peripherals available in something like a PIC or STM32, or if you’re gonna put a CPU in a polling busy-loop, let it be one of those. a dedicated minimal processor so all your timing constraints can be precisely known and managed. if using linux, it’d be a device driver. the idea of doing it in userland like this just drives me crazy.
otoh, isn’t it awesome that you can more or less get the job done without learning/practicing any traditional embedded development skills!
Yeah, I often feel this way too. People miss the distinction between embedded and deeply embedded. Raspi are great for whipping something up with something you have already laying around for proof of concept.
its the difference between soft and hard real time. The pi running standard noobs linux will do soft real time, but will struggle with hard real time. The difference is not so raw performance or processor clock, but cycle jitter. For example we do some high performance protocols in software only, but we spend a lot of time reducing anything that might get in the way. For example even cache hits can cause unacceptable that makes the processor miss the next cycle.
It sounds like the SENT protocol is just on the border between soft and hard real-time, but I would not trust it in a mission critical environment
This program is pretty good, but its still tricky to try to understand the notes in order to get it working in my application.
I bought an LXE3302AL002 in order to try to replicate the result. I noticed the version available for download is slightly different from the one in the video as well. It shows 12 bit in the video and the download is 16bit.
Here’s hoping I can get it to work soon. I don’t suppose anyone else has a handle on it yet?
I have been trying to read data from a SENT based delta pressure sensor through arduino uno board, but my signal looks weird, I feel their is some issue with resolution and baud rates. Can you suggest anything on how to fix this. In Oscilloscope I can see correct SENT waveforms, but through UNO it somehow gets skewed, like lot of data is missing.
were you able to get the proper data?
You could try this code https://github.com/BlinxFox/sent/tree/master