• State
  • Locked Locked
  • Replies 72 replies
  • Subscribers 36 subscribers
  • Views 7160 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UART communications fail in agriculture fields !

Ahmed Mahgoub
Intellectual 825 points


Hello,

I am connecting TivaC with an RF module with UART with baud rate 9600. The system hibernate for 2 hours and wakeup to collect some sensor reading and then send the data to the RF through the UART link and finally hibernate again. The wakeup period is around 5 seconds. It works fine in the lab and in the backyard.

But when installing the system in an agriculture field we record several time fail of UART communications. We designed the system not to hibernate except after sending the data to the RF and added a watchdog timer to restart the code every 10 seconds. We recorded several minutes to an hour trying time till re-establish UART communication and then hibernate !

Some useful notes:

We assumed before it may be the morning dew  but we found the inside of enclosures are dry.

The supply voltage is 3.2 for both the UC and RF.

The system works without errors for several weeks in house or at the backyard. But can not pass a single day in the agriculture field !

There is no noise source in the field and we tested several fields and all give the same UART communication loss.

The enclosures are mounted on the soil and are plastic, nearly air-tight with one cable gland.

Ican force the system to hibernate even under the loss of UART with the RF, but at this time I will lose the data at this time window and I am not sure if the UART communication will be established at the following time or no.

I am open to any ideas.

Regards,

Ahmed 

  • 0
    TI__Guru**** 244440 points
    Hello Ahmed,

    Wouldn't it call for in field debug to first what is breaking the communication?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 825 points

    Hello Amit,

    Yes, but this happens in random time and may be once for 1 minute in the whole day ! We can not follow it up. What we did is isolating some factors like testing it in winter (no high temp), testing it in bare soil, placing desiccate inside the enclosure, testing an enclosure without any cable glands or holes,...
    We are using jumper cables for UART, do you think that has an effect ?

    Regards,
    Ahmed

  • 0
    Guru 27665 points

    Ahmed Mahgoub said:
    There is no noise source in the field

    Are you sure there is no noise?  How have you established that?

    However, you have not established noise as the cause from what I can see so that's not relevant as of yet.

    Ahmed Mahgoub said:
    we record several time fail of UART communications.

    What does that mean? What exactly have you recorded and how?

    Robert

  • 0 in reply to Robert Adsett
    Intellectual 825 points
    Hi Robert,

    The field is bare soil with no transmission line or any instrument or pivot in the surrounding. There is a WiFi tower about a mile and half to the location. We tested another fields and gives the same results.

    We record the UART fail by measuring the time of received data. We adjust the code to send every 2 hours so we expect to see the data at every 2 hours period. If the UART fails, the UC will not be able to communicate with the RF and data would not be send at time, the watchdog keeps restarting the code till the UART re-establish again and data is sent. We record several delays over the day each with a minute up to an hour.

    Regards,
    Ahmed
  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    So

    • you have not measured the noise.
    • you have not checked the output of the uart
    • you have simply measured the receipt (or not) at your remote receiver.

    Basically you have established a failure somewhere in the system.  You have not established where in the system or anything approaching a cause. From the data currently given there is no reason to narrow the cause of the failure to the micro much less the UART peripheral.

    Robert

  • 0 in reply to Robert Adsett
    TI__Guru**** 244440 points
    Hello Robert,

    I agree. It would be more useful to take the test equipment to the field rather than bringing the failing unit to the lab where it always seems to work.

    Regards
    Amit
  • 0 in reply to Robert Adsett
    Intellectual 825 points

    Hi Robert,

    I followed the code step by step with messages on LCD and I found that it stopped at the UART communications between the UC and UART. UC wait forever at this point so you have to restart the code several time until it re-establish the communications and passes this step.
    That made me narrow the search to this point. Moreover, there is nearly no other parts in the system away from the UART that could be verified except a hardware failure in the components and that can't be because we tested a lot of systems and all go with the same behaviour. 

    Do you think dew over the soil surface may affect the crystal ? or the wires connecting the UART can work as an antenna and capture some harmonics of the reflected EM from the soil that interfere with the baud rate ? I also not sure about the change of pressure inside the enclousre if it can affect the crystal !

    Regards,

    Ahmed

  • 0
    Guru 11940 points

    I would instrument the code to record communication over time (i.e. with time stamp), and especially corrupted/failed communication, MCU state and the power parameters (battery voltage). That would probably need an additional output channel (I hope you have one reserved for debugging), and/or spare GPIOs, and some recording system, like a Notebook with appropriate software.

    But when installing the system in an agriculture field we record several time fail of UART communications.

    How about the robustness of your protocol, especially in regard to corruption ? Do you only detect errors, or do you force a retry ?

    My first (wild) guess - you are locked inside your communication state-machine, perhaps in some non-considered error state, sucking you batteries empty.

    My second wild guess - if it is installed on a agricultural vehicle, shaking and vibration might cause contact issues, with repeated reset/restart cycles. The amplitude of those vibrations often scale with the size of the vehicle.

  • 0 in reply to f. m.
    Intellectual 825 points
    Hello f.m.,
    I am following the time stamp of the communications, and the fails appear random. The battery is new and full before and after the fail. The state of the MCU is always stopped at the UART communication with the RF and waits forever except with several restarting until it re-establish communications after a random time !
    I am forcing a retry several times for the code by watchdog timer until it passes the UART communication step.

    As mentioned before, the system works fine inside the lab for several weeks and that proves the code is working. Also, the system is installed on soil ground with no vibration.

    I copy this part from an answer to Robert

    " Do you think dew over the soil surface may affect the crystal ? or the wires connecting the UART can work as an antenna and capture some harmonics of the reflected EM from the soil that interfere with the baud rate ? I also not sure about the change of pressure inside the enclousre if it can affect the crystal ! "
  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    Ahmed Mahgoub said:
    Do you think dew over the soil surface may affect the crystal ? or the wires connecting the UART can work as an antenna and capture some harmonics of the reflected EM from the soil that interfere with the baud rate ? I also not sure about the change of pressure inside the enclousre if it can affect the crystal !

    This is really, really reaching. If I had to guess based on the information available I'd say the problem was a combination of the signal between the two rf units being too weak and your software not robust enough to recover from the resulting communication errors.

    I'd suggest a data logger on the serial lines to record the traffic back and forth.

    Robert

    And if the pressure is high enough to affect the crystal you need to take safety precautions opening that container.

  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    Ahmed Mahgoub said:
    the system works fine inside the lab for several weeks and that proves the code is working.

    Absolutely not! Do not ever start to think that.

    Robert

    "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." C.A.R. Hoare

  • 0 in reply to Robert Adsett
    Intellectual 825 points
    Thnx a lot Robert,

    I believe the signal is strong enough between the MUC and RF along the UART. The battery are fully charged and new and I measured the voltage after the error and it was the same.
    I am not sure about the data logger as the error may happen once a day and it will be hard for someone to follow up the system in the rural field all over 24hours.

    Regards,
    Ahmed
  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    Ahmed Mahgoub said:
    I followed the code step by step with messages on LCD and I found that it stopped at the UART communications between the UC and UART.

    This is a very strong indication you have a problem in your communications code.

    Robert

  • 0 in reply to Robert Adsett
    Intellectual 825 points
    Actually, I have a simple code with UART communication only and it stops at this step. I am using UART In Blocking for receiving that makes the code stops till it gets the UART data and every time the code stops here. I can bypass this step and force the code to continue by using UART Non Blocking for receiving but this will not solve the issue and the data is not transmitted through the RF.
    Some tests I performed, I have heated the MUC and RF to a very high temperature in the lab with the wires and it is working.
    I wish I have a trick to change the pressure of the enclosure and see the effect on the crystal frequency.
    For the RF, I am choosing baud rate 9600 but I have no information about its crystal or the calculations performed.
  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    Ahmed Mahgoub said:
    I believe the signal is strong enough between the MUC and RF along the UART.

    You should be measuring.  Maybe even by measuring drop out/corruption of one-way transmission.

    Ahmed Mahgoub said:
    I am not sure about the data logger as the error may happen once a day

    That's why you use a data logger.  Let it capture a weeks worth of data and then collect it for analysis.

    Robert

  • 0 in reply to Robert Adsett
    Intellectual 825 points
    You are right about that Robert.
    Can you guide me to a data logger to purchase ? Normally I am using oscilloscope.
  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    Looks like a SW issue Ahmed.

    You really should install a datalogger. At a minimum log the comms to and from the RF unit. Preferably also include some state machine information from your protocol.

    Robert

  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points
    I've not needed one for serial data logger but I know several are available. Olimex appears to sell a kit/bareboard version.

    Maybe someone can suggest one? If necessary you could probably build inexpensive ones from eval boards.

    Robert
  • 0 in reply to Ahmed Mahgoub
    Guru 47900 points

    While I respect & often admire the tech work of your "hi-level" responders - have they not ALL "glossed over" the potential for a, "Hibernation Issue?"

    Should you not "awaken" fully/properly from Hibernate - would not that well explain your problem?

    I'd suggest - at least temporarily - eliminating hibernation from the mix.   You may achieve this via the supply of power via a motorcycle battery or something similar - which maintains (proper) voltage to the MCU - again w/ALL Hibernation code (really all of it) banished from the scene.

    And if this was my issue - I'd secure (several) commercial systems - as similar as possible to yours - and install these and monitor & observe results.   (just in case there is some "unwanted/intrusive" RF or other atmospheric activity - able to plague your system...)

    Too many variables are currently in play - KISS dictates one battle du jour - maintains communication (and sanity) far better than, "many balls in the air."

  • 0 in reply to cb1
    Guru 27665 points
    Definitely a point.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    Definitely a point.   

    Must be (some) justification for "big bucks!"   {kidding}

  • 0 in reply to cb1
    Intellectual 825 points
    Hello Cb1,
    I really appreciate your answer and it was one of my main concerns to connect a solar panel with the battery or provide a large battery and make the system works without hibernate. What stops me is that it is working in the lab. I believe that the code is the same, so if it can wakeup fully from hibernate in the lab, that means it must wakeup fully in the field. What do you think about this assumption ?
  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points
    Ahmed, I think that is reason for thinking it behave properly in the lab but you may have missed a corner condition that shows up in the field. Also behaves properly and is correct are two quite different conclusions, the latter requires more rigorous testing for any degree of confidence.

    I think there is a more important reason to consider following cb1's advice. The system is quite complex even without introducing hibernation. Removing that from the test while searching for this problem will simplify your task considerably.

    I wouldn't try to make it permanent. As cb1 suggested just take a large lead-acid battery and use it as the backup supply for testing. I wouldn't be surprised if your unit didn't draw much more than leakage current and a sealed lead acid battery is relatively easy to get (even if it is heavy).

    Robert
  • 0 in reply to Robert Adsett
    Intellectual 825 points
    Ok, that means to replace a timer or a 2 hours delay in the code instead of the hibernation and give it a try. Next trip to the field is not nowadays, so I have time to change the code and prepare an enclosure for a 12A battery. If you have any other suggestions I am open to them.
  • 0 in reply to Robert Adsett
    Guru 47900 points
    Indeed Robert & Ahmed - your "awakening from Hibernation" while outside & exposed to greater temperature & environmental extremes - may over-challenge. And that can be confirmed via "quick/dirty/easy" testing. (Robert, Amit's @ cb1's favorite!)

    Kill the hibernation for now - I'd place high stack of chips on that as your issue!
  • 0 in reply to cb1
    Guru 10570 points
    It wouldn't be the smallest justification we've seen

    Robert
  • 0 in reply to Ahmed Mahgoub
    Guru 10570 points
    I'm not as convinced as cb1 that hibernation is the problem.

    In either case I'd suggest adding any data logging you can. The goal is if hibernation does not have an effect then you want to capture as much data as you can to narrow down the problem area. If hibernation does effect it you want to be able to simply change the program and collect data from a failure that you can now compare to known good operation.
    You can throw away data you don't need, you can't create data you didn't think to gather.

    With your test setup so far away you want to gather as much data as you can since you don't have the luxury of quickly re running to gather more data.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 117855 points

    Robert Adsett72 said:
    I'm not as convinced as cb1 that hibernation is the problem. 

    Let the record now show - on this date - at this time - and at this place - friend Robert "hopes" that Hibernation - under widely varying environmental conditions - proceeds w/out a hitch.   This vendor's past LM3S was notorious as "current hog" and "dismal" (to be kind) at hibernation.   Is it likely that - in one fell swoop - all of that is corrected?   And - have we not (recently) learned - that a "normal/customary" signal edge - "proves too fast" for TM4C123?

    Data Logging may make sense - but not before the (far) faster, easier, less expensive method of "escaping" from Hibernation.   Note that a "locked/dead" MCU cannot produce too much (meaningful) data - a logger filled w/such data is not of high value...

  • 0 in reply to cb1_mobile
    Intellectual 825 points
    I have gathered some information remotely from the working site. Most of the errors (if not all of them) appeared between 7AM-9AM and 7PM-9PM. These information are collected along the previous 3 days at a bare soil field in Florida. I installed several systems in the same field and all of them experienced this error at least once in this time period.
  • 0 in reply to Ahmed Mahgoub
    Guru 11940 points

    There had been a night in between for me, so I chime in here again late ...

    As Robert, I believe you have a problem with the communication-related part of your software. Lab testing (as often), did obviously not cover your issue. And like others suggested, instrument your code to trace and find it on the field.

    Most of the errors (if not all of them) appeared between 7AM-9AM and 7PM-9PM.

    Does that mean much ? Not sure - I think this is more on the "effect" side than the "cause" side. How long had the devices been running before in these instances ?

    For the datalogging, I would suggest to include software states (like function entry/exits, state variable changes, etc.), not only communication data. Since I don't know your hardware and software, I can just give general ideas. You can use ETM capabilities (tracing), a regular communication channel (I prefer UART here), or even GPIO toggles. And I would choose a Notebook PC as logger - it is flexible and easily adapted to this (and the next) logging task, and can be powered from the vehicle.

  • 0 in reply to f. m.
    Guru 117855 points

    f. m. said:
    I would choose a Notebook PC as logger...

    Greetings f.m. - always good to note your presence .   (here & @ mkt. leader's ARM forum)

    Yet - is a "Notebook PC" best & proper for an "unwatched, remote field - and would not that notebook require special environmental protections?   (and perhaps environmental hardening to "resist" rain, wind, airborne objects - and the occasional Everglade's python - lured by the heat of that very notebook?    I'm unsure - but hasn't poster Robert "released" several of his "pets" - in just that manner?)

    As it may be the UART which has failed - can the suggestion of employing another UART to "pass log data" - prove wise?

    Flag of Hibernation failure - under challenging environment - still blows high, hard, fast when viewed by this reporter...

    Data Logging has merit - but (most likely) after Hibernation has been tested/verified...

  • 0 in reply to f. m.
    Intellectual 825 points
    greeting f.m.
    Yes the error time window mean much. It is the time where there is the highest temperature change at sun shine and sunset periods. This temperature variation change the pressure inside the enclosure that is one of my suspects to drift the frequency of the crystal so missing the UART synchronization between the UC and RF. Moreover, I still suspect EM noise generated from the soil at certain time that may disturb the UART signal.
    There is no way to leave a notebook or any other instrument without a well enclosed isolated boxes boxes. May be if there is a data logger that can work standalone for a week, I can leave it inside of one of the enclosures to report the UART activities.
  • 0 in reply to cb1_mobile
    Intellectual 825 points
    cb1_mobile, I am oriented to your suggestions about peripheral ready state after hibernation wakeup in harsh environment.
    My code arrangement is like that

    int main(void){

    PLL_Init(); //initialize PLL
    UART_Init(); //initialize UART
    GPIO_init(); //initialize GPIO--->I think does matter with our issue

    ////////////////////Enable watchdog timer that restart the code if 10 seconds passes without hibernate////////
    SysCtlPeripheralEnable(SYSCTL_PERIPH_WDOG0);
    WatchdogReloadSet(WATCHDOG0_BASE,SysCtlClockGet()*10);
    WatchdogIntEnable(WATCHDOG0_BASE);
    IntEnable(INT_WATCHDOG);
    WatchdogResetEnable(WATCHDOG0_BASE);
    WatchdogEnable(WATCHDOG0_BASE);

    ///////////////////Hibernate setting//////////////////////
    SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE);
    HibernateEnableExpClk(SysCtlClockGet());
    HibernateRTCSet(0);
    HibernateRTCEnable();
    HibernateRTCMatchSet(0,3600*2);
    HibernateWakeSet(HIBERNATE_WAKE_PIN | HIBERNATE_WAKE_RTC);

    SysCtlDelay(60000000); //that gives over 2 seconds delay

    ///////////This is the UART communications where we send data to the RF and expect to receive the response. In the field the SW stuck at the first UART_InChar() (I can change it to Non blocking to continue running the code but will not solve the problem) and the watchdog keeps restarting the code for about 1 minute to 1 hours until restablishing the communications
    UART_OutChar(out_data); //sending data to RF module
    in_data=UART_InChar(); //receiving the response from RF module, code stops here

    //////////hibernate//////////////
    SysCtlDelay(800000);
    HibernateRequest();
    }

    Do you think the hibernate setting part must be before UART_init and PLL_init ? I mean does the hibernate setting slightly drift the clock frequency that was set before by PLL and UART and this may be magnified under hash environment conditions to loss the UART communications ?
  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    As it may be the UART which has failed - can the suggestion of employing another UART to "pass log data" - prove wise?

    Yes.

    One of things you need to know is whether there is data being sent to the micro, and sent from the micro. If the RF unit simply stops sending data to the UART you would get the apparent symptoms described.

    Agree with f.m. that you want to include state information from the micro as well, but I would not instrument function calls for precisely the reason you mention, it would flood the log. However, that might be something needed in the future. If the UART is failing you will see in the log(s) that one side of the interface works but not the other, likewise if the RF unit is either failing or transmission/reception is failing.

    Best approach would be three serial streams logged (maybe to separate time stamped logs)

    1. data sent from micro to RF
    2. data sent from RF to micro
    3. Internal micro state information (There are data loggers which would gather time stamped bit change information. that would allow the use of micro GPIO instead of the UART)

    Personally I'd probably not use the laptop if I could avoid it because of battery issues. It is however, flexible and if you have a battery source and protective box might be a good option. An off-the-shelf SBC might be as well.

    My major reasons for suggesting the logging be included as soon as possible are

    • the long test cycle time
    • the long delay between tests (which aggravates the first)

    When your test cycle is measured in days, you approach tests differently than when it is measure in minutes. You have a lot of time to analyze logs while another test is running. Throwing away irrelevant data is easy. I have, in the past gathered multiple MB of data to find the few hundred bytes that show the problem.

    In the best case you can trigger the logger to stop collecting some short time after the fault condition appears but that may be the test you setup to run while analyzing the results from the first run. Using such a trigger allows collecting much more detailed data w/o fear of losing the information around the point of failure.

    Robert

  • 0 in reply to Robert Adsett
    Guru 27665 points
    Note: I wouldn't delay testing to get a logger installed, but if I could get one before the test I'd certainly want to put it on the system.

    Robert
  • 0 in reply to Ahmed Mahgoub
    Guru 47900 points

    Ciao Ahmed,

    My small tech firm has long resisted any use of vendor's "Hibernate" - earlier I detailed our (unhappy) past experience.   Thus myself & crack staff are not optimal for hibernate code review.

    The longer I review & consider your issue - the more convinced I become that some way/how the "Release from Hibernation" does not proceed as smoothly/properly as one hopes.

    Poster Robert urges "Data Log" due to "Long Test Cycle."   Can't you (immensely) speed that test cycle via use of a, "Shake/Bake Chamber?"   That's how most all of our military & medical designs proceed - serves as a check of Software, components, entire board and interconnects!   Surely deserves your high consideration.

    The fact that you report the greatest incidence of failure - coincident w/greatest temperature change - appears to be a valuable finding.   Is your protective "chamber" (really) proper & suitable for task?   Might a series of properly designed "relief ports/valves" insure that internal pressures cannot reach destructive and/or "failure-causing" levels?   (such "reliefs" usually are located along the bottom side - to prevent moisture ingress.)   I'd question enclosure makers and/or others who have first-hand experience in "managing" such environmental conditions - you're unlikely to glean such focused detail here.   (my belief)

    Yet more support for my "Hibernation as culprit" - while hibernating your MCU draws the least current - then suddenly awakens - might this make your MCU and board even more susceptible to changing temperatures?   (I believe so)

    How do we know your board & interconnects are all proper?   Is yours a "pro board?"   Are UART signal levels between MCU & radio - at all times - fully w/in specs?   Sudden change in temperature is a key means of test/verification.   (i.e. "Shake & Bake" Chambers - which identify & "weed out" flawed board, component & interconnects - is a classic method to best insure board & component robustness & design integrity.   You may contact local test facilities - and/or friendly local firm so equipped - and run tests upon (several) of your failing boards.

    Killing Hibernation (still) tops my list as, "Ahmed's First Step!"

  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    Ahmed Mahgoub said:
    Yes the error time window mean much.

    Maybe, I'd stay skeptical about that you don't have a lot of data to support that conclusion.

    Ahmed Mahgoub said:
    It is the time where there is the highest temperature change at sun shine and sunset periods.

    Yeah, that's a bit of a jump to conclusion

    Ahmed Mahgoub said:
    This temperature variation change the pressure inside the enclosure

    Seriously? How much? I didn't have the impression you had placed the device in a pressure vessel. How does that compare to normal atmospheric variation.

    Note: I was quite serious about my comment that if you think this is happening you need to take safety precautions when opening the case.

    "The frequency of a properly designed crystal oscillator changes less than 5 x 10-9 when the environment changes from one atmosphere of air to a vacuum."1

    Ahmed Mahgoub said:
    , I still suspect EM noise generated from the soil

    Neat trick. How did you measure radiation generated from the soil? What's the mechanism by the way?

    Robert

    1 - http://www.oscilent.com/esupport/TechSupport/ReviewPapers/IntroQuartz/vigstab.htm

  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    If the RF unit simply stops sending data to the UART you would get the apparent symptoms described.

    But Robert - do we (really) know that?   Really?  

    What I believe to be "known/agreed" is that the MCU - via UART - passes data to Ahmed's radio.   And (then) that radio data is not received.   I do not see - or have not absorbed - your claim that the RF unit sends data to the UART.   (and as past designer of military RF systems - while "handshakes have value" holding a vital commo channel "hostage" to such (successful) TWO Way message passage is NOT best practice!)

    I dislike the, "Use another UART" approach as I fear that, "Should one UART fail - similar fate awaits (very) related peripherals!"   (i.e. any other UART)

  • 0 in reply to cb1
    Guru 27665 points

    cb1- said:
    Robert Adsett
    If the RF unit simply stops sending data to the UART you would get the apparent symptoms described.

    But Robert - do we (really) know that?   Really?  

    The report is the micro is stuck in a UART loop (from the report it appears to be waiting for a reply), so yes as far as the information we have is accurate we know that if the RF unit stopped sending data we would get this symptom. What we don't know is if the information is actually being sent from the RF unit.

    cb1- said:
    I dislike the, "Use another UART" approach as I fear that, "Should one UART fail - similar fate awaits (very) related peripherals!"   (i.e. any other UART)

    Why? UARTs are quite reliable. Even in the unlikely case that this UART is failing there is no reason to expect the UART on the logging device to fail. It would be a different board/manufacturer.

    Robert

  • 0 in reply to cb1
    Intellectual 825 points
    Cb1, the RF is sending message back to the MCU through the UART. This can be acknowledgment message or the RF module itself can collect some data and send it back to the MCU.
  • 0 in reply to Robert Adsett
    Intellectual 825 points
    I did not make measurements for the pressure or EM noise. However, I found the enclosures after a while sucks the lids and deforms the gaskets or the isolation around the cable glands. That led to the installation of a moisture plug in the enclosures to equalize the pressure but there is no consistent results or observations about its effects.
    For the EM noise, what we noticed is that other WiFi devices failed completely to work on the soil surfaces including iphones connected to WiFi tower while it works when we raise the device above 45 inches. That was noticed all over the field that is diverse and large. We don't have any explanation about this till now.
  • 0 in reply to cb1
    Intellectual 825 points
    I am pretty convinced of what you are saying. We will start pushing experiments to simulate temperature change on enclosure.
  • 0 in reply to Ahmed Mahgoub
    Guru 27665 points

    Ahmed Mahgoub said:
    I did not make measurements for the pressure or EM noise. However, I found the enclosures after a while sucks the lids and deforms the gaskets or the isolation around the cable glands.

    Unless you have an unusually stiff enclosure that would not take very much pressure difference, maybe only 1 PSI or so. The larger the enclosure the less pressure difference needed. To affect the crystal by the 1% or so you need to affect the serial port you will need a lot more than that. I doubt the pressure difference you noted will change the frequency by more that its tolerance but you'd have to check with the manufacturer to get the sensitivities.

    Ahmed Mahgoub said:
    For the EM noise, what we noticed is that other WiFi devices failed completely to work on the soil surfaces including iphones connected to WiFi tower while it works when we raise the device above 45 inches. That was noticed all over the field that is diverse and large. We don't have any explanation about this till now.

    What immediately occurs to me is conductivity. I'm not sure there is even a mechanism for soils to emit E-M radiation1 much less strong enough to interfere with an RF transmitter. If you have a HAM club or University nearby I think you could find someone who would actually know.

    Robert

    1 - ionizing radiation is another thing entirely.

  • 0 in reply to cb1
    Intellectual 825 points
    My small tech firm has long resisted any use of vendor's "Hibernate" - earlier I detailed our (unhappy) past experience.
    Can you guide me to this past experience forum ?
  • 0 in reply to Ahmed Mahgoub
    Guru 47900 points
    You may visit the Stellaris forum - which includes the original LM3S series of MCUs - and reports of "Hibernation Issues" are numerous. You may also review the MCU manual for such past devices - specifically noting the "current draw" during "hibernation."

    The newer devices are much improved - if they've improved to the extent you require - such remains to be discovered.
  • 0 in reply to Robert Adsett
    Guru 47900 points

    Ahmed Mahgoub said:
    For the EM noise, what we noticed is that other WiFi devices failed completely to work on the soil surfaces including iphones

    and

    Robert Adsett said:
    What immediately occurs to me is conductivity.

    What other terrain features are nearby?   What is the "water table?"   How far to the nearest Power Transmission Lines?   Cell Tower?

    Can you raise your MCU enclosure above that 45" mark - while employing proper cables to connect between the enclosure & sensors?   Has this even been considered?   Might a "ground rod" - driven a minimum of 3' into the earth - and tied to your MCU board's system ground - improve?

  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    in the unlikely case that this UART is failing there is no reason to expect the UART on the logging device to fail.

    I was not targeting the UART on the logging device - instead a 2nd UART w/in the MCU.   (that was my understanding of this alternative method)

    Should one UART become disturbed - and that's frequency caused/related - I believe the case is reasonable that "all" UARTs become suspect...

  • 0 in reply to cb1
    Guru 27665 points
    That's part of what we want to find out by logging isn't it? Along with how the RF unit is responding.

    If the data logging from an independent stream stops at the same time as the communication with the RF unit that is useful information.

    However, there is much useful information even w/o an independent logging stream. The most immediately useful is logging the communication to/from the RF unit and that has the plus of not disturbing the SW under observation.

    Robert
  • 0 in reply to cb1
    Guru 27665 points
    That frequency thought is interesting though. It's highly unlikely that the crystal itself is varying sufficiently to cause an issue but it is possible that a cold solder joint or a bad load on the crystal could cause an issue, or that the PLL setup occasionally got confused.

    Might be work having a measurement of frequency. A long flash LED would catch very gross changes and a 'scope would be more accurate. If an external LED has a 10s flash rate a large difference is readily observable. Have to use a 'scope or frequency counter if you get close to the one or two percent range though. Below 1% it's not likely to matter.

    Robert
  • 0 in reply to Ahmed Mahgoub
    Prodigy 60 points

    Sorry - because of the trans-atlantean distance, I'm taking some "timeouts" ...

    It had not been clear to me how and where the device is installed, so a Notebook might really not be the best option. However, while debugging/collecting data, I would not leave the setup alone. A day in the field could be a great experience for a software engineer ...

    But as others pointed out, temperature drift is not that much critical for quartz oscillators, at least in the usual electronics range. Only take into account that a core frequency drift is multiplied by the PLL factor. That should be relatively easy to measure in the lab, including it's influence on UART timings. Mechanical load (shock, vibrations) are more critical to a quartz.