osPID malfunction using internal switch regulator

[rob_lee]

#3598

This post was originally under the general category, but I have now moved it under hardware as it would seem to be more applicable. I should also point out that my profession is electronic hardware design in a CAE/CAD context and that tinkering with Arduino based products has become a bit of a hobby as well as a useful way to test out simple product ideas.

It seems others have experienced similar issues (thank you “Ausi cracked”) but I realise that even osPID guru’s will be unable to provide much assistance if the problems can’t be recreated on the test bench.

My osPID hardware was purchased fairly recently (2 months ago) and came with the latest firmware (1.60) already installed. I am currently using it to control an electric propagator.

My set up consists of a simple ‘K’ type thermocouple and a Fotek 25A SSR for the actual power control. osPID power is provided either by a laptop USB when using the front end OR a 12VDC plug pack in standalone mode. NOTE: only one power source is ever connected at any one time.

Thus far I have only experienced problems using the osPID in standalone mode with a nominal 12VDC via the rear jack. The failures are very sporadic, sometimes it fails repeatedly after only a few minutes, other times after a few hours of operation.

I have tried various DC plug packs (about 6 in all, linear and switching) but none of them provide a satisfactory solution. I haven’t tried a pure DC source (i.e. a 12v car battery) yet though.

When I reconnect the front end I see that the set-point has changed (from about 23deg) to 250, the output has switched to relay 2 and the timing window has reset to 5 seconds (i.e. reverts to defaults).

If I power cycle the osPID after it has faulted the relay usually begins to toggle every second or so, until I reconnect the front end and send some sensible values back to it.

Recently I have also noticed that to make it stable, I don’t need the front end gui running. Merely providing USB power to the device seems to keep it happy. That leads me to my current work around, use a 5V USB plug pack not the rear jack until the issue can be properly resolved.

It has been running now faultlessly on USB power for the last couple of days and is very stable and accurate to within 0.5 deg C.

I have to admit that I am beginning to suspect a problem with the on-board switching regulator but I cannot confirm this at this point in time.

The following is my list of things to try when time allows:-

1. Thorough visual inspection of the main board psu area (make sure everything is populated and correctly orientated).
2. Try a pure DC source (i.e. 12v car battery)
3. Test for under/over voltage or noise on regulator output

Perhaps someone at rocketscream could comment?

Any other ideas would be appreciated

[Cracked]

#4013

Thanks for the update, and for contributing to the forum. It was beginning to feel rather empty in here.

I have been running my ospid stand alone for a while now as it seems most stable that way. Only issue I have in this setup that is I dont know if my switching time setting is being retained, and I dont have any record of my actual temperatur profile. The 5s default isnt fast enough for my application (0.06 sec is the lowest I can set with stable operation). I am also using a fotek 25A SSR interestingly.

Keen to see the results of your test.

[redwire]

#4014

Here’s a few suggestions on things to check- I’m also an EE.
-Try run it grounded. When you connect the USB cable, you providing the osPID an earth ground path, which may not be happening with your (2-prong) AC adapters. Then EMI can get into the MCU via the thermocouple.
-For the osPID regulator, check if C3 is correct and not cracked. I would measure the 5V rail and see if it’s off, or add 100uF and see if that fixes it.
-I’ve seen the fusebits overlooked in the ATmega328 – that the correct crystal/resonator is chosen- if wrong it can make the osc. weak and sensitive to EMI.
Also that the brownout detector is enabled and set to high threshold. I’m not sure if the watchdog is used.

[rob_lee]

#4015

Hi all, thanks for the suggestions thus far.

I had some downtime today for a few hours so I disassembled the unit and had a good quick look over the main board but visually it looks fine. I didn’t have enough time for a thorough test to the point where it craps out though.

I stuck a scope probe on the 5V and that also looks fine, there was a small amount of ripple ( <10mV )as you might expect but that seems to be in line with the datasheet and shouldn't bother the logic side of things at least.

Have a question, How is the brownout detector implemented and how would I test it ??

By “grounded” I assume redline is referring to mains earth. I did think about doing this via pin J3-2 on the output card and It will probably be the next most reasonable thing to try. The SSR is in a separate metal box with a heatsink and the only convenient place to pick up the earth point so I will need to rewire things slightly to do that.

[rocketscream]

#4016

Hi Rob,

Thank you for posting the issue here.

The brownout detector is enabled by the default settings on the Arduino IDE. As the osPID main board uses the Arduino Duemilanove bootloader, the brownout is
set at 2.7 V which is not helpful when we are running at 5V/16 MHz operation. We will change the brownout fuse setting to 4.30 V from now onwards.
To test the brownout functionality (with the current fuse setting), basically you need to drop the voltage below 2.7 V, then it should restart the processor.
If a restart does happen, you should be seeing the firmware revision splash screen on the LCD.

By “grounded” I assume redline is referring to mains earth. I did think about doing this via pin J3-2 on the output card and It will probably be the next most reasonable thing to try. The SSR is in a separate metal box with a heatsink and the only convenient place to pick up the earth point so I will need to rewire things slightly to do that.

Pin J3-2 is a GND, you can try to connect the earth (carefully) to it.

Have you try using the USB power coupled with the external DC source?

[rob_lee]

#4017

Not being able to test while the osPID is in use has given me some more time to think about the problem and possible tests that can done to rule stuff out.

I’m going off the idea of “grounding” things for the following reasons:-

1. it works fine on USB power which is “definitely not grounded” (double insulated PSU’s, L and N only). This applies to both laptop power and the 5V DC plug-packs that I have tried thus far.

2. It would result in an unwanted return path for DGND which I don’t like the idea of at all. In my high speed product design world it’s a sure way of failing emc compliance. I’m not convinced that it would make a product less susceptible, and perhaps the opposite is true.

3. If an earth fault were to occur it might blow up the osPID.

As far as emc susceptibility goes osPID seems to be very robust as I would expect in a multi layer design with power planes. None of my RF sources (wifi, zigbee etc.) have any noticeable affect on it at practical distances even with an un-screened thermocouple and there are no other sources nearby to speak of.

The brownout issue is still of interest to me so I have done some testing on my ‘arduino uno smd’ which has the same processor. I haven’t played with this feature before and didn’t to risk “bricking” the osPID at this stage.

I used avrdude and USBtinyISP to dump the efuse data (really confusing as un-used bits in efuse read as 0’s on this processor) and found that the uno board also had it set to 2.7v by default.

It is my intention to repeat this process on the osPID and re-test at the earliest opportunity (probably 2 weeks time).

[rob_lee]

#4018

At long last the temperatures here in UK are a bit more spring like, enabling me to do some more testing to get to the bottom of this issue.

Having recently installed Atmel Studio 6 for my AVRISP MKII programmer the task of checking and setting fuses as well as downloading software has become much easier.

Looking at the BODLEVEL fuses, as expected they were set to the default 2v7 as opposed to the 4v3 (intended for 5v operation).

I changed these fuses to the 4v3 setting but THE RESULT IS the Ospid is being CONTINUOUSLY reset. I.E. The BOD function is being activated.

The Target voltage indicated by the device programming tool is 4.6v (When powered from the PC USB port or a 1A USB MAIS adapter ). I’m assuming this is read by the AVR programmer from the ICSP pins, not by the processor itself internally, but not sure about that.

According to the datasheet there would need to be a signal lower then 4.3v for 2uS minimum to trigger the BOD function and I don’t think that I saw anything like that last time I hooked up a scope to it. (or maybe it goes away when I do)

For now I have DISABLED the BODLEVEL entirely, will see if problem goes away or not.

Interestingly my Arduino UNO SMD board reads a target voltage of 4.9v (using the same 2 sources for power as for the Ospid mainboard) and is perfectly happy with the BODLEVEL set to 4v3.

In any case there is a schottky diode drop in the case of the Ospid USB power, whereas the UNO uses a FET, so that would explain the difference in the voltage readings anyways but not the reason for the brownout operation when set to 4.3.

I need to test this again using the internal regulator 7 – 30v dc input to see if still resets then at the 4.3v BODLEVEL.

Begining to think it is a hardware fault on my main board

Needs a specific post I think

HMMMMMM The Mystery Deepens !

[rocketscream]

#4019

Rob,

I think it’s best you send us the unit back for us to check.
Drop us a mail. We wanted to know the root of the problem too.

[rob_lee]

#4020

I agree, especially considering the other problems I have experienced.

Will arrange to return the main board

[Author]

Posts