Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 20:08 13 Jul 2025 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : S.E.N.T. on Micromite

Author Message
Octatron
Newbie

Joined: 01/04/2015
Location: United Kingdom
Posts: 27
Posted: 05:34am 03 Apr 2015
Copy link to clipboard 
Print this post

Recently at work I used the Micromite to assemble a bit of equipment to simulate sensor inputs to one of our products. The sensors produced a PWM waveform which can easily be generated with a Micromite. This worked very successfully and the equipment has been replicated at least half a dozen times for use in our labs.

We now have a new product in development which has the same type of sensor but now they no longer use a PWM output but use a SENT bus. This is slightly new to me. According to Wikipedia "The SAE J2716 SENT (Single Edge Nibble Transmission) protocol is a point-to-point scheme for transmitting signal values from a sensor to a controller. It is intended to allow for high resolution data transmission with a lower system cost than available serial data solution"

The question is has anyone any experience of using the SENT protocol on the Micromite.
 
redrok

Senior Member

Joined: 15/09/2014
Location: United States
Posts: 209
Posted: 08:11am 03 Apr 2015
Copy link to clipboard 
Print this post

Hi Octatron;
  Octatron said  We now have a new product in development which has the same type of sensor but now they no longer use a PWM output but use a SENT bus. This is slightly new to me. According to Wikipedia "The SAE J2716 SENT (Single Edge Nibble Transmission) protocol is a point-to-point scheme for transmitting signal values from a sensor to a controller.
The wiki is little light on the details.
However, each nibble appears to be sending hex, (16), numbers as a, more or less, pulse width.
There would be 16 different pulse widths for the 16 hex numbers.

I'm trying to figure out how it works.
Lets say the unit of time is maybe 10uS. Its probably less than this.
Then each symbol sent would be between 120uS and 270uS:
Sync = 560uS
0 = 120uS
1 = 130uS
2 = 140uS
...
E = 260uS
F = 270uS
Pause = 120uS to 7680uS
Timing is only based on the fast falling edge of pulses with a width of about 5 ticks or 50uS in this case.
The rising edge is slower but should not be critical.

I don't think this would be to hard to decode.
(Not that I know how to do it.)
  Quote  It is intended to allow for high resolution data transmission with a lower system cost than available serial data solution"

The question is has anyone any experience of using the SENT protocol on the Micromite.
Not me but I'm interested.
redrok

Ok, I dug up a nice document that describes SENT in engineering terms.
(Not the totally cryptic "Standards" description.)
Microchip: Single-Edge Nibble Transmission (SENT) Module
Apparently the time "Tick" can range from 3uS to 90uS, so my 10uS I used above was within the range.
The tick time can be in error as much as 20%. However, the transmitter and receiver must both have agreed on this tick time before starting. (I assume the sensors you are using have this basic tick time in their specification.)

Transmitting should be relatively easy.

Receiving is the hard part.
Three methods could possibly be used:
1. Do 10 Period inputs. But this probably isn't workable.
2. I'm thinking that using falling edge interrupts and logging the internal clock. On each interrupt log 11 clock values. Then do the subtractions and decode the information. I suspect the timer clock is not fast enough though.
3. Write a C function and do the same thing using the CPU's fast clock.
redrok

Edited by redrok 2015-04-04
 
redrok

Senior Member

Joined: 15/09/2014
Location: United States
Posts: 209
Posted: 07:42am 04 Apr 2015
Copy link to clipboard 
Print this post

  redrok said  Transmitting should be relatively easy.

Receiving is the hard part.
Three methods could possibly be used:
1. Do 10 Period inputs. But this probably isn't workable.
2. I'm thinking that using falling edge interrupts and logging the internal clock. On each interrupt log 11 clock values. Then do the subtractions and decode the information. I suspect the timer clock is not fast enough though.
3. Write a C function and do the same thing using the CPU's fast clock.
redrok
Apparently this can't be done as the resolution of the "Timer Counter" is only 1mS.

This would be easy to do with the "Propeller" of which I'm much more familiar, because their fast 32 bit counter runs at 80MHz.

Can anyone tell me if there is a fast counter connected to the master clock that can be used with MMBasic?
Possibly it can be read with a "PEEK" command?
redrok
 
Octatron
Newbie

Joined: 01/04/2015
Location: United Kingdom
Posts: 27
Posted: 05:46am 05 Apr 2015
Copy link to clipboard 
Print this post

Thanks Redrok for your response. I came across the Microchip info as well, it's a shame the module is for the PIC24 series processors, it doesn't seem to be available for the PIC32MX series. Though the Microchip protocol description is very useful.

Actually all I'm interested is sending a signal with the SENT protocol. The application is to simulate an automotive sensor which feeds into an electronic control unit.

I had not come across this protocol before, in an automotive application, comms is usually handled with CAN, LIN and PWM.

I'm not sure how in the protocol descriptions they can justify it as "lower system cost", as it appears to me that there is more of an overhead in soft and hardware to implement it than say PWM, which the original sensors used that I was working on.
 
Print this page


To reply to this topic, you need to log in.

The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025