Posts made by Claude Robitaille

To answer my question: yes, it is persistent. But since it is not clearly stipulated (at least in the help) this should not be rely upon....like anything unspecified!!

Re: How to change TimeZone?

Are the changes made using the command line tool onion persistent? The help is silent about this.

@Lazar-Demin said in Omega2 LTE just launched!:

Omega2S module does feature a Watchdog

When I wrote Omeage2s in meant the plural as I have many. Also I was under the impression that the Omega2S and Omega2S+ were simply repackaged regular Omega2/+. But I guess there are few additions.

The documentation indicates that the HW reset pin is only on the Omega2S+, not the Omegae2S. But this cell thing is stuff with the + variant so it is covred.

OTOH, the documentation does not talk about the watchdog. Can you point me in the right direction?

Yes, init.d can be a partial solution. But about init.d itself? (Issues are most of the time software bugs, but there is definitely other type of issues that could cause init.d to fail).

Any hope for support of 100% unattended operation? By that I mean that the device always recovers from any kind of HW and SW issues? I have had Omega2s stop working where only a power cycle would recover (the reset input is process by software so if somehow the OS goes away the reset never performs), Also, my own code could stop working itself (yes, it is possible to add a lot of safeguard, monitoring functions, etc.).

I real production grade unattended operation capable product need to have a watchdog. Here, the only solution due to lack of hard reset on the Omega, is to have the watchdog perform a power cycle should it timeout. Is there anything of that nature on this module?

Also, I am looking at the MAX16998 to drive a MOSFET on the ground return of the omega. But is there a simpler solution? Any suggestions?

@Jake-Fulford did yo manage to create a product grade solution with the Omega? I put my project on the back burner for a while but now I am back at it. I guess some external watchdog + power cycling circuit is needed but I am just wondering if you thought of something.

@Lazar-Demin Sorry, all I have is my own PCB or the power dock. My own PCB has an Ethernet port but that too stops working (the link LED on the switch I am connecting to is Off).

@Lazar-Demin I am on 0.2.0 b186. I tested last week and there was no update but I see now that there is one so I will give it a try. (0.2.0 b198)

@ccs-hello Yeah... and it is not like I did not checked I am running the latest and "greatest".....:-(

My omega2+ would stop to respond to pings over WiFi after a while (like 30 minutes). It also stops to respond over wired Ethernet at the same time. After realizing it works perfectly elsewhere in my home, I attached an antenna and the problem disappeared. So, somehow, the weak wifi signal causes the device to break and stop processing anything; not only the Ethernet port stopped working but also the toggling of a GPIO stopped.

It is because the wifi kernel code is jamming the OS when the signal is weak? Also noted is that the device never recovers; a simple out of connect situation due to a weak signal should show moments of no connection and moment of connection (I let the device run overnight and it never recovered).

@ccs-hello 2 things
1 - I went deeper and found out that depending on where my device was in my home the problem would go away / be present. At the location where the problem was present, I attached a Wifi antenna and the problem disappeared...so the problem is related to a weak Wifi signal. But the consequence were that everything stopped, including Ethernet. Not good and very surprising!!

2 - RESET and FW_RESET never worked, even when the device was being successfully pinged. Those 2 pins are not very useful.... I know that FW_RESET can be converted to GPIO but my device is still pretty much at factory reset (except for a script that toggles a different GPIO)

@Rodrigo-Fructuoso Did you ever resolve this? I have a situation where my omega2+ stops after a while and although I want to fix this I also want to have a working watchdog solution... Should I design an external watchdog or can I rely on the MT7688&?

Ok, that worked.

I never suspected the wall powered USB hub not to be able to deliver the needed power to the Omega. Probably a cheap hug from unknown brand...( i used the same cable, so it is not it).

Also, I never suspected the battery controller not to be able to merge the power from the battery and the USB. Not very useful. Also, more than likely, when there is power outage the switch will most certainly cause a hiccup and a reboot of the CPU. This raises a couple of questions:

• regardless of the dock and it power circuitry, is there any form a reliable brown out detector and "corrector"?
• what about watchdog, there was a question on this list but nobody answered?
• how can you expect this to work years of unattended operation?

I have a very bizarre situation. I can only get the Omega2+ / Wifi to work when my power dock2 is powered only from the battery. The moment I plug in a USB power source, the module's amber LED turns off. Power cycling (using the power button) does not bring the module back to life. If I unplug the USB source and power cycle again, the module works properly and the Wifi connection to my home network comes up. Every time.

I am obviously talking about the micro USB connector.

Hi,

on the topic of doing a generic gpio support library; I am looking for a solution that is highly portable. To that effect, the "native" Linux kernel gpiolib (why did they use the lib suffix? For me a lib is something userland, not kernel....) is a good thing. This http://lxr.free-electrons.com/source/Documentation/gpio/sysfs.txt describes the sysfs API. (Note that some other driver/system also uses the sysfs interface but differently, the "files" are not the same. Notably the Next Thing's CHIP is significantly different).

My question relates to the interrupt driven GPIO input. Or activity detection. I would like to get the time of the input event; and I would like to be as precise as possible. I saw in the kernel code (gpiolib, at http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L708) that the kernel does register the time of the event. I even see pass it up (http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L620) but I do not see or understand how to access this information from the userland. The documentation regarding /sysfs/class/gpio is silent on this. Anyone knows the answer?

Thanks