January 2023 - OvmsDev - Open Vehicles

Warning in Duktape
by Michael Geddes 09 Aug '24

09 Aug '24

There's an unused variable 'dcc' warning in the below code. It seems that the 'Perform the callback' is not being 'performed! Is this deliberate? //.ichael void DukOvmsCommandRegisterRun(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) { ESP_LOGD(TAG, "DukOvmsCommandRegisterRun(%s)",cmd->GetName()); auto it = MyDuktape.m_cmdmap.find(cmd); if (it == MyDuktape.m_cmdmap.end()) { ESP_LOGE(TAG, "Command '%s' cannot be found in registry",cmd->GetName ()); return; } else { DuktapeConsoleCommand* dcc = it->second; // Perform the callback } }

3 6

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

Subaru Solterra
by Solterra 11 Jun '23

11 Jun '23

Any interest in adding support for Subaru Solterra?

4 9

ESP-IDF v4 / v5 - baby steps
by Ludovic LANGE 06 Mar '23

06 Mar '23

Hi list, I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc... In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ). I'm now trying to revive this effort, and after some work managed to have: * OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing) (/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/ The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic) You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimenta… (In the README.md, there is a short notice at the top with a few useful informations) I'm now reaching out here mostly for : * gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files My next steps could be (of course, subject to feedback) : 1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same. (Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.) # The guidelines I tried to follow: * Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refer… * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… # Missing features: In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon: * I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/514… and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment. Let me know your comments and questions. Best regards,

4 27

Active GPS power consumption
by Mark Webb-Johnson 07 Feb '23

07 Feb '23

Re: https://www.openvehicles.com/node/3545 I think it worthwhile having this discussion here. Synopsis seems to be: Our modem design uses the SIMCOM reference design to power the active GPS antenna from VBAT. This increases power consumption (powering the active antenna), even if the GPS is turned off in software. There is an alternative approach using pin 44 and the AT+CVAUXV / AT+CVAUXS commands to enable/disable and/or adjust voltage. Would be interesting to see the exact power readings and impact this change would make. I will try to get these this weekend. Regards, Mark

2 2

OVMS support for PSA eCMP vehicles - Opel Corsa-e, Peugeot e208 et al.
by Harald Linden 03 Feb '23

03 Feb '23

Good evening list, so, Citroen quietly published the following news at some point during the last week: "As the supporting platform and 2G/3G technology are outdated, posing additional security risks and vulnerabilities to data breaches, we have no choice but to switch off these services from 1 January 2024. This will affect all radio navigation systems that use a personal SIM card." It can currently be assumed that this will affect all cars based on the eCMP platform as listed here: https://en.wikipedia.org/wiki/Common_Modular_Platform#eCMP Currently OVMS does not mention any support for these cars. I've searched this lists' archives and so far nobody seems to have tinkered with the platform at all. What options do you see for me, as a technically inclined user to change that? Currently, off the top of my head I can think of: - remote hands on affected hardware - collecting funds to help with an implementation with a kickstarter - ...that's about it. I know, I'm not bringing much to the table. I would like to hear your thoughts on this situation though, as I guess, at least some of the Opel/GM owners here have been through the same before. regards Harald

2 1

Hyundai Kona Electric devs?
by Christos Oscar Kambiselis 31 Jan '23

31 Jan '23

Hi, Are there devs that are focused mainly on the Kona? I would be willing to help with CAN data acquisition and interpretation, can't really help much on the software side since I only have basic knowledge. Oscar

3 2

Strange esp32can / Wifi mode interaction
by Michael Balzer 27 Jan '23

27 Jan '23

I've begun reducing my car module's power usage by switching off GPS and Wifi AP mode when not needed, and found a rather strange behaviour: When switching off Wifi AP mode (i.e. running in client mode only), a short while after the car's CAN bus has been shut off, the esp32can bus runs into a stuck bus-off error state. This looks like this: (…vehicle switches off…) E (113345) can: can1: intr=1791 rxpkt=903 txpkt=882 errflags=0x8000d9 rxerr=0 txerr=8 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 (…txerr raising up to…) E (113345) can: can1: intr=1808 rxpkt=903 txpkt=882 errflags=0x204800 rxerr=0 txerr=128 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 I (114345) v-vweup: PollSetState: AWAKE -> OFF Normal up to here – the bus is now off. I normally wouldn't see another CAN log entry now until the next on/off transition. But /with Wifi in client mode/, after a couple of minutes new errors appear, leading to a lot of IRQs and ending in a stuck bus-off state: I (409995) wifi: new:<6,2>, old:<6,0>, ap:<255,255>, sta:<6,2>, prof:1 E (411345) can: can1: intr=2106 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=128 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412485) can: can1: intr=6655 rxpkt=903 txpkt=882 errflags=0x804802 rxerr=0 txerr=136 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412495) can: can1: intr=6659 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=136 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412495) can: can1: intr=6696 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=144 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412505) can: can1: intr=6698 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=144 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412505) can: can1: intr=6707 rxpkt=903 txpkt=882 errflags=0x80480b rxerr=0 txerr=152 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412505) can: can1: intr=6708 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=152 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412815) can: can1: intr=7933 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=160 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (412815) can: can1: intr=7936 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=160 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (413015) can: can1: intr=8727 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=168 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (413015) can: can1: intr=8731 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=168 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=150 wdgreset=0 errreset=0 E (417565) can: can1: intr=26805 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=176 rxinval=0 rxovr=0 txovr=0 txdelay=2 txfail=150 wdgreset=0 errreset=0 E (417565) can: can1: intr=26810 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=176 rxinval=0 rxovr=0 txovr=0 txdelay=2 txfail=150 wdgreset=0 errreset=0 I (420025) wifi: new:<6,0>, old:<6,2>, ap:<255,255>, sta:<6,0>, prof:1 I (421055) wifi: new:<6,2>, old:<6,0>, ap:<255,255>, sta:<6,2>, prof:1 E (421145) can: can1: intr=40992 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=184 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (421145) can: can1: intr=40995 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=184 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (421405) can: can1: intr=42033 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=192 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (421405) can: can1: intr=42037 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=192 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (421425) can: can1: intr=42116 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=200 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (421425) can: can1: intr=42119 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=200 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (421485) can: can1: intr=42328 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=208 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (421485) can: can1: intr=42331 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=208 rxinval=0 rxovr=0 txovr=0 txdelay=3 txfail=150 wdgreset=0 errreset=0 E (427385) can: can1: intr=65746 rxpkt=903 txpkt=882 errflags=0x80480b rxerr=0 txerr=216 rxinval=0 rxovr=0 txovr=0 txdelay=5 txfail=150 wdgreset=0 errreset=0 E (427385) can: can1: intr=65750 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=216 rxinval=0 rxovr=0 txovr=0 txdelay=5 txfail=150 wdgreset=0 errreset=0 E (428585) can: can1: intr=70500 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=224 rxinval=0 rxovr=0 txovr=0 txdelay=6 txfail=150 wdgreset=0 errreset=0 E (428585) can: can1: intr=70505 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=224 rxinval=0 rxovr=0 txovr=0 txdelay=6 txfail=150 wdgreset=0 errreset=0 E (428585) can: can1: intr=70515 rxpkt=903 txpkt=882 errflags=0x80480a rxerr=0 txerr=232 rxinval=0 rxovr=0 txovr=0 txdelay=6 txfail=150 wdgreset=0 errreset=0 E (428585) can: can1: intr=70517 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=232 rxinval=0 rxovr=0 txovr=0 txdelay=6 txfail=150 wdgreset=0 errreset=0 E (428845) can: can1: intr=71523 rxpkt=903 txpkt=882 errflags=0x80480b rxerr=0 txerr=240 rxinval=0 rxovr=0 txovr=0 txdelay=6 txfail=150 wdgreset=0 errreset=0 E (428845) can: can1: intr=71526 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=240 rxinval=0 rxovr=0 txovr=0 txdelay=6 txfail=150 wdgreset=0 errreset=0 E (433465) can: can1: intr=89884 rxpkt=903 txpkt=882 errflags=0x804803 rxerr=0 txerr=248 rxinval=0 rxovr=0 txovr=0 txdelay=7 txfail=150 wdgreset=0 errreset=0 E (433465) can: can1: intr=89887 rxpkt=903 txpkt=882 errflags=0x8048d9 rxerr=0 txerr=248 rxinval=0 rxovr=0 txovr=0 txdelay=7 txfail=150 wdgreset=0 errreset=0 E (435495) can: can1: intr=97936 rxpkt=903 txpkt=882 *errflags=0x4cc0a *rxerr=256 txerr=384 rxinval=0 rxovr=0 txovr=0 txdelay=8 txfail=150 wdgreset=0 errreset=0 E (435495) can: can1: intr=97937 rxpkt=903 txpkt=882 *errflags=0x48c00* rxerr=256 txerr=351 rxinval=0 rxovr=0 txovr=0 txdelay=8 txfail=150 wdgreset=0 errreset=0 OVMS# can can1 status CAN: can1 Mode: Active Speed: 500000 DBC: none Interrupts: 97938 Rx pkt: 903 Rx ovrflw: 0 Tx pkt: 882 Tx delays: 30 Tx ovrflw: 42 Tx fails: 150 Err flags: *0x00040c00* Rx err: 0 Tx err: 0 Rx invalid: 0 Wdg Resets: 0 Wdg Timer: 5 sec(s) Err Resets: 0 Err flag means: IRQ 0x04 = IR.2 Error Interrupt (warning state change), SR 0x0c = TX done + free. From here, RX and TX are both blocked, i.e. no vehicle state change is detected, no data sent or received. The only way to resolve this state before my latest commit was to reboot the module. I've debugged the "can stop" command for the esp32can driver and added an auto reset for this condition. I think the state is the known bus-off recovery hardware error (see "TWAI_ERRATA_FIX_BUS_OFF_REC"), which means our workaround implementation doesn't work, at least not in this case. I've tried a small modification after looking at the current TWAI driver, but the idf driver does a lot of things differently now, so that's not easily applicable to our driver. With the CAN auto reset, the above cycle happens about every 5-10 minutes as long as the Wifi mode is client (scanning or fixed). The issue disappears as soon as I start the Wifi apclient mode, and reappears as soon as I go back to client mode. This is 100% repeatable. Any ideas? Is this possibly some kind of EM interference, as the CAN bus isn't terminated in the module? But if so, wouldn't this be more likely to happen with AP mode enabled? Should I try closing J4 to enable the CAN1 termination? Has anyone seen a similar effect? Btw, this is a production 3.3 module (first batch). Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

my little OVMS better sleep story
by Patrick Stein 25 Jan '23

25 Jan '23

Dear all, as I’ve written before I had the problem with OVMS using too much power when sleeping. I updated the battery calibration code for better recognizing the correct voltage as I have 4 modules under my control and they are in 0.1 voltage range around the 11-13 volt after calibration ( a range I think might be better than the 195.7 factor used by OVMS in the past. As I’ve seen the module sometimes still boot I changed the idf core module that when the module one started and read the calibration if would keep sleeping even before a second core was beeing started when it was below the set sleep voltage but above 6 volts ( so the module would not sleep in usb mode). In sleep the modules would still draw 200 mWatts - I suspect the modem sleep mode is not correctly working. The sleep code was working fine and in the code I wrote in a 4k memory block the current voltage and how often that voltage was seen before the next voltage change ( two bytes each ,so the bytes 120 136 would mean 120 times 13.6 volts ) , so I could see the voltage droping after a couple of hours. The i3 Battery drained at about 0.2 Volts in 12 hours - too much for my liking as my i3 does stand for a couple days in a row sometimes in an underground garage with no easy access to the 12v battery. So I finally decided a hardware solution - I solderd myself a zero power adapter for the db9 ODB-OVMS cable and plugged the ovms module into the usb plug of the i3. Now everything I need works perfectly as power to the USB bus is quit by the car after a few minutes the car is parked. I’m using the MQTT Interface to send data to my MQTT Server where the data is aggregated with the bmw connected drive data - were I found out that mqtt can bus mileage is off by 1 to the bmw connected drive and the display. From there I feed a little self written iOS program where I can now continue to see location, soh and journeys and get immediately get a push notification for charge start and stop events. I have pushed the idf and ovms changes to my clones of the ovms repositories onto github.com/jollyjinx , but as I no longer need them there is no need to cleanup the code and write a pull request for me. And as I’m no longer writing c-code day in day out there are probably many bugs in them, but for someone in need might find this post in the future for reference. A few impressions what I can now see with OVMS data (before I only used connected drive and could not see all values e.g.chargespeed ) which is great. Many thanks to Michael Balzer for his feedback - Patrick

1 0

SIM7600 Registration Denied
by Mark Webb-Johnson 18 Jan '23

18 Jan '23

I’ve been fighting a problem for the past few months with registration getting denied on T-Mobile in USA using Hologram and our new 4G SIM7600G modem. Without cellular connectivity at home, it hasn’t been easy to recreate this, but I found a solution: Finally, with a good high gain antenna on my external wall facing the nearest cellular tower a couple of km away, I can get cellular (and even GPS with the little black puck) connectivity. So back to the two issues we are having: The FPLMN blacklist in the modem lists a bunch of cellular networks we are blocked from connecting to (including the ones we need). There have been reports that the connection to hologram works and is maintained, but the OVMS never connects to the v2 server. To address #1, I have extended the “cellular cmd” command to try to capture the output from the modem. There is no simple way of knowing when the command has completed, so for the moment I just look at data returned from the modem on the command channel, and stop when it hasn’t changed for a second or so. That now works like this: OVMS# cellular cmd AT+CRSM=176,28539,0,0,12 +CRSM: 144,0,"FFFFFFFFFFFFFFFFFFFFFFFF" OK OVMS# cellular cmd ATI Manufacturer: SIMCOM INCORPORATED Model: SIMCOM_SIM7600G Revision: SIM7600M21-A_V2.0.1 SVN: 01 IMEI: (redacted) +GCAP: +CGSM OK If required, we can send a relatively simple command to clear the FPLMN blacklist. It seems to work well, but I still need to test it wider (especially over v2 protocol commands, where I think we might have a recursion problem). So on to issue #2 that has been much harder to find. Finally, working with Hologram, I discovered that the problem seems to be in our handling of CREG network registration messages. I found a module with this problem, and manually issuing commands I found: AT+CREG? Registration Denied AT+CGREG? Registration Denied AT+CEREG? Registered Roaming It seems that the E-UTRANS (some 4G LTE carriers) won’t show the registration status correctly in AT+CREG. I guess they are refusing GSM (3G) connections from us (aka ‘Registration Denied’) while allowing 4G LTE. But as we only use the AT+CREG status to know whether we are connected to the network, the result is we can’t detect the E-UTRANS LTE connection and think registration has been denied. Connected to Hologram, but no data (or v2 server) connection. I did some research, and can’t find a definitive answer to how best to do this (especially as we have both 3G and 4G options, still support 2G, and a lot seems to depend on the individual cellular carrier options). So I implemented it as best I could. I re-ordered the registration statuses to be in lowest priority order, then created m_netreg_d[3] to store the registration status for each of the three types. Finally, I changed it so that m_netreg reflects the highest registration status. That way if CREG says RegistrationDenied, and CEREG says RegisteredRoaming, I treat it as RegisteredRoaming. This seems to work (on my test bench at least), and I now plan to deploy for wider testing. Code is committed and built as 3.3.002-45-g42546636 on the main firmware site. I would gratefully appreciate feedback on this. Regards, Mark.

4 21