AVR in vehicle datalogger is confusing me!

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,
I am facing a strange issue with RS485 data. Here is a brief description of the system.
The system is fitted in a heavy vehicle, a truck (Diesel Engine)
consists of a display unit and a sensor unit ATMEGA16A on the display unit and ATTINY2313 on the sensor unit.
The MEGA16A sends a request to the TINY2313 over a RS485 bus at 4800 Baud and the TINY2313 (sensor part) returns back the raw value to the MEGA16A (the Display unit).

UART to RS485 and vice versa is done using MAX485
UART on the MEGA16A is Software UART at 4800 bps (Hardware UART is used for USB data Logger)
RS485 Cable is about 30 meters twisted pair four core cable (two for data and two for sensor supply which is 24V)

The system was thoroughly tested in my workshop and worked perfectly as desired for almost a month.

Now the system has been installed in the vehicle it was logging the data with some errors.
I assumed that the sensor is getting a burnout reset probably because of cranking. There is a software loop when the ATMEGA16A doesnt get any data for a certain amount of time, it logs sensor open.

now after almost a day of testing in the vehicle, the sensor sends erratic values which is beyond the limit.

customer says that during cranking, the maximum voltage drop is 17V
I am getting confused on which point this is happening.

should i use a CRC check on the data?
Use filters and inductors on the power entry side? (space is very limited on the sensor side)
Reject values above max sensor value?
Recycle the sensor power supply on after error values?

All crystals used are external and clocked at 7.3728Mhz. Voltage regulator on both ends is LM2576-5V. Input voltage to the system was initially from the cigar lighter port. now connected directly to the vehicle battery.

need suggestions badly! :roll:

thanks in advance

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

good shielding of any signal path, full swing oscilator settings, bypass capacitors...
this is for start..
then study something about EMI

Computers don't make errors - What they do they do on purpose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd suggest you didn't test for the expected environment. You need to filter and clamp every signal the ventures beyond your pcb including the power. You're going to have sags, spikes etc. does the truck have a two way radio? Cell phone? You might need some RF filtering as well. Your sensor data should be checked for validity - garbage in, garbage out.

You also need to consider alternator noise and induced spikes. There are a number of devices that draw high currents. The lights alone are significant - think of the current flowing when the brake lights are applied.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Vehicles are very hostile evironments for electronics. A lot of ugly stuff going on, e.g. voltage spikes, magnetic fields etc..

Quote:
about 30 meters twisted pair four core cable

Shielded?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

full swing oscilator settings

Hi KIIV_cz I did not understand what you mean by this.

hi Kartman,
Its difficult to reproduce that vehicle environment in workshop.
I have added proper inductors in the supply line of the avrs with adequate decoupling caps.

I suppose the LM2576 is a 52Khz Switcher that should cut some noise. what say?

Quote:

Your sensor data should be checked for validity - garbage in, garbage out
what is the best way to do this? any algorithm?

Hi JohanEkdahl,
I'm afraid its not shielded. shielded twisted pair cables are hard to find. thus i thought of reducing the baudrate to 4800

Oh i forgot one thing, both the display part and the sensor is mounted inside a metal enclosure. and firmly bolted to the vehicle body which is ground.

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From mega16a datasheet:

Quote:
Crystal Oscillator
XTAL1 and XTAL2 are input and output, respectively, of an inverting amplifier which can be configured
for use as an On-chip Oscillator, as shown in Figure 8-2. Either a quartz crystal or a
ceramic resonator may be used. The CKOPT Fuse selects between two different Oscillator
amplifier modes. When CKOPT is programmed, the Oscillator output will oscillate will a full railto-
rail swing on the output. This mode is suitable when operating in a very noisy environment or
when the output from XTAL2 drives a second clock buffer.
This mode has a wide frequency
range. When CKOPT is unprogrammed, the Oscillator has a smaller output swing. This reduces
power consumption considerably. This mode has a limited frequency range and it can not be
used to drive other clock buffers.

Normal mode can be affected even by serial interface located right next to XTAL pins

Computers don't make errors - What they do they do on purpose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

printf("Help, my %s does not %s",Tiny,IsAlive);


Is it a hardware problem or a software problem?

If a node failed then it should have reported an error, switched to the safe state, halted waiting for maintenance. You have redirected asserts to EEPROM, haven't you? Also small stack dump wouldn't hurt.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte,

Unfortunately, No!!
this is a demo system and wanted to see the performance of the same. Now the vehicle where this is fitted, is gone for a test run and will return back after doing 2000Km. I am planning to visit the customer, awaiting their availability.
i need to put some error dump mechanism. and be a victim of at least 500km torture test :shock: with a topping of high temperature, humidity and off course dust.. :mrgreen:

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just i remembered a small project i did few years back.
it was the same RS485 bus and the distance was about 100-110Mtrs.

The system did run perfectly fine in a heavy industrial environment with loads of motors and hydraulic press working.
the only difference is that there i used a normal CAT-5 cable. used one pair and the other pair was grounded.
Maybe that is the reason why it worked properly or maybe automotive noise is more harsh than industrial noise.

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm afraid its not shielded. shielded twisted pair cables are hard to find.

Really? Ordinary shielded Cat5 network cable? (Granted, you get four pairs while you do not need more than two..)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

KIIV_cz,
I dont think the problem is on the MEGA16A (display Unit) side
because the logging is on, LCDs are working fine. Also note that i am sending a byte to the sensor unit which is 0xF0
The sensor is getting the value and replying. This cant be a oscillator issue and they are talking to each other.

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Ordinary shielded Cat5 network cable?

But normal CAT-5 cables are not shielded.. are they??

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When cranking, there is a voltage drop in the battery to engine ground cable. If sensors are at engine ground, and supply is at battery ground, there may be problems. Try moving the supply ground to the engine.

It all starts with a mental vision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

saumya73 wrote:
Quote:

Ordinary shielded Cat5 network cable?

But normal CAT-5 cables are not shielded.. are they??

there are several types of CAT5 cables:
UTP - unshielded twisted pair
STP - shielded twisted pair
FTP - foil twisted pair

Computers don't make errors - What they do they do on purpose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Its difficult to reproduce that vehicle environment in workshop.
I have added proper inductors in the supply line of the avrs with adequate decoupling caps.

I suppose the LM2576 is a 52Khz Switcher that should cut some noise. what say?
Quote:

Your sensor data should be checked for validity - garbage in, garbage out


Well your test wasn't thorough then was it???
What testing did you do? Run it for a week it it worked? Not a particularly good test.

Your lm2576 will do a good job of making noise since it is a switcher.

Since we have no idea of your sensor, lets make a few guesses - no checking on your serial comms. Should you have checking? Of course. Be it a checksum or crc. You would then be able to detect comms errors. Try something like nmea0183 - there should be heaps of code out there as gps receivers use this protocol.
What is the input to your sensor? Basically, at any point in your system you should be able to detect an error. If the input is analog it should be between a known range - if it is outside this range, it is declared an error. Analog or digital inputs should be filtered in hardware and software. Avoid using external interrupts if possible.
Once you can detect errors, you can keep a count of them. This gives an indication as to how robust your system is.

Surely you can get some shielded twisted pair cable? What protection do you have on the rs485 bus? Is it biased correctly?

The cause of your problem is most likely a number of small things. You need to pay careful attention to the details.

Here's some simple workshop 'tests'
Use a piezo gas lighter to zap your enclosures and cable
Get a 1hp electric motor. Place near to your equipment. Turn on and off multiple times
Get an arc welder and drape your comms wires near its wires. Do some welding.
Does your equipment withstand these tests?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's another test: Run a cable out of your lab window to a car on the street. Wind the cable a few rounds inside the engine compartment. Make sure you pass the starter, the ignition coil and the generator a few times. Send realistic signals through the wire while you have someone starting, running and stopping the engine. Look at the signals at the other end of the cable with a oscilloscope.

Or even just look at power supply lines you run through a twisted pair in the cable.

Re shielded CAT-5: http://en.wikipedia.org/wiki/Foi...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman,
I am not making any validation to the serial data. As i wanted to see the data without any validation so that i can keep track of real errors.
Now that it started giving out erratic values (786.9, 786.3, 786.6, 787.0) it kept on revolving around that value. Actual value should not be more than 250.0
Now the confusion is I am being able to send requests to the sensor and the sensor does reply back. is the bus disturbed at all?

Quote:

What protection do you have on the rs485 bus? Is it biased correctly

I have provision for biasing but in the lab test only it failed. so didn't put up biasing resistors.

good tests described by Kartman and JohanEkdahl would love to give it a try!
8)

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have no idea of how your system works as you've not told us. You've been offered a number of general suggestions, but if you want more specific assistance, we'll need to know a bit more about your system. We don't even know what your sensor is sensing!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

We have no idea of how your system works as you've not told us

This is a simple straight forward system. I am sensing the fuel level in the fuel tank the sensor gives pulse output proportionate to the fuel in tank. I am just measuring the pulse duration with ATTINY2313A (QFN Package) and sending the values over the RS485 Bus when requested.

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Obviously it is not quite as simple as you anticipate!

From what you've described, it would appear the tiny is responding correctly and the data is finding it's way to the mega16 correctly. That leaves the tiny's reading of the sensor signal.
Hopefully the sensor and circuitry is suitable for use in a potentially explosive or flammable environment. Electricity - even 5V does not mix well with flammable liquids . Let's assume the sensor is specifically designed for the purpose and you've followed the standards and manufacturer's recommendations.
The sensor can output, no pulse,a minimum pulse, a maximum pulse and a pulse somewhere in between to give an indication of fuel level. The first three cases are used to detect failure. The sensor just measures level, but the level is not static - when the truck moves, so does the fuel, so your actual level is changing. You need to smooth the data so that the human is presented with a reasonable display of fuel level. So what is an acceptable rate of change? You could do a rough estimation based on the power of the truck engine, the energy rating of the fuel and 30% efficiency to come up with the rate of consumption. This will give you an idea of what change is expected. The the measured change is faster, then this is measurement noise to be filtered.

Does your tiny perform the above? If not, you've got some work to do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The good thing, of course, is that the fuel level doesn't change quickly.

One therefore can send the data value many times, even with a high system error rate, and have a reasonable display at the far end.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the tiny is responding correctly and the data is finding it's way to the mega16 correctly

Here what i can see is that the data is not transferred correctly, then it would have given values within limits.
This could be because of one of the two reasons.
1. the internal counter is messed up due to noise.
2. the serial data is corrupted due to noise.

in the first case, after recovering from a noisy state, it should be normal after some readings but its not.

i suspect its the whole serial train of data that is messed up once and the data is corrupted.
could be like it messed up the start and stop bits a bit shift which makes the whole data corrupted.
I have seen that when this data is corrupted, it gives data around 786.9, 786.3, 786.6, 787.0

Quote:

The sensor just measures level, but the level is not static - when the truck moves, so does the fuel, so your actual level is changing. You need to smooth the data so that the human is presented with a reasonable display of fuel level. So what is an acceptable rate of change?

Yes this is done already, I do get minor value changes when the vehicle comes to stop or the driver brakes the vehicle suddenly. in both the cases there is a small difference that i have seen 1.0 Ltrs to 1.5 Ltrs In this case i can easily make the changes to the average filter to eliminate this minor issue.

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what could be the best possible way in software for error free data?
should i lower baudrate? or should i use constant strings along with every data, so that the other part reads the constant string and if it matches, it reads the actual data.

A friend of mine suggested using a power inductor in series to the power supply and the instrument. its just that i dont know much about power electronics, im afraid to implement something which i dont know

_____________________ Love and Peace keeps PrOgraMmerS happy :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've already suggested means of ensuring error free data.

The internal counter messed up due to noise? Seems like you've got some work to do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay! The customer wants me to visit their facility. but late this month. will keep this topic alive and updated!
thanks a lot for the lovely replies and suggestions :)

_____________________ Love and Peace keeps PrOgraMmerS happy :)