January 2018 - OvmsDev - Open Vehicles

Android App v3.12.2 in Play Store
by Michael Balzer 07 Apr '19

07 Apr '19

Whoa. Our first public App update since …drumroll… June 2014 :) I didn't get any bug reports for my 3.12.2 beta release, so I just finished some last details and uploaded it. May take some hours to appear in the Play Store. As change history has grown a bit beyond the allowed 500 chars for the release info, I've added a history page to the Wiki: https://github.com/openvehicles/Open-Vehicle-Android/wiki/History I'm afraid it's just the condensed gitlog though. I hope users won't get confused, sure could need some refinement. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

10 47

Collecting information on the Fiat 500e
by Jason Perkins 15 Feb '19

15 Feb '19

OVMS team, As an owner of a Fiat 500e I was very interested when I stumbled across this project on the TMC forums. The Fiat factory telematics system deactivates 3 years from the original vehicle sale and is non renewable. I think FCA wants to kill the whole system at this point (it's been replaced with the corporate UConnect system) so another solution would be ideal. I have a 2013 500e with deactivated telematics, and our roommate has a 2014 with working telematics. If any data could be captured from the car with working telematics (branded as Fiat Access) to assist integrating OVMS I'd love to help. The Fiat Access telematics provides vehicle location, battery level, tire pressure, setting the charge schedules, locking / unlocking the car, and starting the climate control. I believe the actual control unit was adapted from some kind of remote-disablement system used in europe (the Fiat literature calls this the Vehicle Tracking Module). The Fiat has a normal J1962 plug, but does not have OBDII protocol support. Like the Kia Soul the powertrain CAN on pin 6 / 14 and the body CAN on 1 / 9. There's no telling how long the telematics will keep working on our roommates '14, so doing a capture sooner than later would be good. I'm open to any suggestions on how best to do this. The car related diag tools I have on hand are: ELM327 Bluetooth, Ross-Tech VCDS (For VW / Audi Products), and AlfaOBD (which can talk to most of the modules in the 500e - but not the VTM :( ), and an adapter to swap the CAN wires so a standard interface can get to the Body CAN. Thanks! -J

5 28

GPS / NMEA integration
by Michael Balzer 11 Jul '18

11 Jul '18

I'm currently working on the NMEA module. The MUX channel is working, but I don't get a GPS fix. I've tried all GPS commands and now suspect my SIMCOM module having a hardware issue. I'm doing this: OVMS > level debug OVMS > power simcom on …wait for the MUX to be ready, then issue… OVMS > simcom muxtx 4 AT+CGPSNMEA=1 OVMS > simcom muxtx 4 AT+CGPS=1,1 …now the SIMCOM begins sending NMEA $GPGGA lines once per second looking like this: D (2937174) SIMCOM rx: f9 05 ff 35 24 47 50 47 47 41 2c 2c 2c 2c 2c 2c ...5*$GPGGA,,,,,,* D (2937174) SIMCOM rx: 30 2c 2c 2c 2c 2c 2c 2c 2c 2a 36 36 0d 0a 60 f9 *0,,,,,,,,*66*..`. Normally the modem should get a GPS fix within about 1-2 minutes and begin filling data in the $GPGGA record. But my modem won't, it just keeps sending empty fields. Can someone please try this with his/her module? To disable the GPS receiver, issue: OVMS > simcom muxtx 4 AT+CGPS=0 Thanks & regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

7 30

v3 hardware disconnecting from v2 server
by Tom Parker 27 Mar '18

27 Mar '18

Hi, I've been struggling for some time with intermittent disconnections from the v2 server. I've switched from hologram to a local cellular provider's sim card, to match my v2 hardware which is very stable and the problem persists. With the car stationary, the connection seems very solid, but on the move, it usually disconnects within half an hour. I'm running 98169d8862db2bbc4bea14d013883f26ee6afb4e (from 2018-01-19) with idf 5bf85d06d8c402fe30ecb1bf9c09d5e69b923b2f and xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz. I tried logging to the sdcard and on my desk powered by USB that seemed to work well, but it didn't work very well (only a few lines logged to the sdcard and then the whole system seemed to crash) when powered from the OBD2 port. I haven't tried to debug that. With the sdcard logging turned off, and logging with minicom I can get good diagnostics. It would appear that the v3 hardware thinks it is still connected and continues to send data, but the v2 server thinks the client has disconnected. I've got ovms logs which have regular lines quoting the local time from the modem, and server logs from the dexters-web server which I think are not UTC. Anyway, 05:47 in the server log corresponds to 17:47 in the ovms v3 log. The relevant lines of the logs are below. On the server log the ovms v3 hardware client is #72 and then #94. We can see the client sent and the server received S messages at :47:15 and :47:32. The client sent more messages that were not received by the server, more than I've transcribed here (full log attached). The server recorded a disconnect at :48:29, but the client recorded the transmission of messages in it's log for minutes after that. I did a simcom status command which reports that everything is connected, and then I pressed the button to reboot the module. The server records a new connection at :54:07 and the messages logged as transmitted on the client start to correspond with the messages logged as received on the server start again. Thoughts on how to proceed? Another oddity not shown here but included in the full logs is that the client sent a lot of D messages shortly after reconnecting. Server Log: 2018-01-26 05:47:15,36664,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96' 2018-01-26 05:47:15,36665,'#72 C rx msg D 128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0' 2018-01-26 05:47:15,36666,'#72 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2018-01-26 05:47:15,36667,'#72 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees' 2018-01-26 05:47:32,36717,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96' 2018-01-26 05:48:29,36926,'#72 C got error: Connection reset by peer' 2018-01-26 05:50:08,37206,'#93 A got login' 2018-01-26 05:51:24,37485,'#36 A rx msg A ' 2018-01-26 05:52:53,37742,'#93 A got error: Broken pipe' 2018-01-26 05:52:54,37745,'#72 A got login' 2018-01-26 05:54:07,37937,'#94 C got login' 2018-01-26 05:54:13,37957,'#94 C rx msg S 87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0' 2018-01-26 05:54:13,37958,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,59,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:13,37959,'#94 C rx msg L 0,0,0,0,0,0,104,0,0,0,0' 2018-01-26 05:54:13,37960,'#94 C rx msg W 0,0,0,0,0,0,0,0,0' 2018-01-26 05:54:13,37961,'#94 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,1,1,NL,2degrees' 2018-01-26 05:54:15,37964,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,60,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:15,37965,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,61,28,1,0,0,13.011,0,0,128,0,0' Serial Console Log: OVMS > I (79663340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79663340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0 I (79663340) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,0,0,0,0,0 I (79663350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees OVMS > D (79665360) simcom: rx line ch=3 len=11 : +CSQ: 10,99 D (79665360) simcom: rx line ch=4 len=11 : +CSQ: 10,99 OVMS > D (79674380) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79674390) simcom: rx line ch=4 len=11 : +CSQ: 13,99 OVMS > D (79678420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79678420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:26+52" D (79678420) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79678420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79678420) simcom: rx line ch=3 len=2 : OK OVMS > I (79681340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96 OVMS > D (79683370) simcom: rx line ch=3 len=10 : +CSQ: 9,99 D (79683370) simcom: rx line ch=4 len=10 : +CSQ: 9,99 OVMS > D (79692410) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79692420) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79708420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79708420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:56+52" D (79708420) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79708420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79708420) simcom: rx line ch=3 len=2 : OK OVMS > D (79713470) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79713470) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79716420) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79716420) simcom: rx line ch=4 len=10 : +CSQ: 0,99 OVMS > I (79724340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79724340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,55,79724,30,1,1,1,13.022,0,0,128,0,0 I (79724350) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,55,0,0,0,0 I (79724350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,0,1,NL,2degrees OVMS > D (79738360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79738360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:26+52" D (79738360) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79738360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79738360) simcom: rx line ch=3 len=2 : OK OVMS > D (79740490) simcom: rx line ch=3 len=10 : +CSQ: 4,99 D (79740500) simcom: rx line ch=4 len=10 : +CSQ: 4,99 OVMS > I (79741340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,388.50,96 OVMS > D (79764490) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79764490) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79768360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79768360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:56+52" D (79768360) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79768360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79768360) simcom: rx line ch=3 len=2 : OK OVMS > D (79773490) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79773500) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79779500) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79779500) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > I (79785340) ovms-server-v2: Send MP-0 S89,K,0,0,stopped,standard,75,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.00,96 ... OVMS > simcom status SIMCOM Network Registration: RegisteredHome State: NetMode Ticker: 25111 User Data: 0 Mux Open Channels: 4 PPP Connected on channel: #2 PPP Last Error: None GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected ... I rebooted the module and it did the normal connection dance ... D (48359) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:53:57+52" ... I (57609) ovms-server-v2: Status: Connecting... OVMS > I (58219) ovms-server-v2: Connection successful I (58219) ovms-server-v2: Status: Logging in... I (58219) ovms-server-v2: Sending server login: MP-C 0 pwLSijW/3qAZ6z0LOBHbGS rnkkhqHUA6zeZqLx1q1Tow== NZLV3 OVMS > I (58889) ovms-server-v2: Got server response: MP-S 0 QTjRAp8ZQPJQV1UXnepldQ w1vWpIrRR9+eot9z3uslgw== I (58889) ovms-server-v2: Server token is QTjRAp8ZQPJQV1UXnepldQ and digest is w1vWpIrRR9+eot9z3uslgw== I (58899) ovms-server-v2: Status: Server auth ok. Now priming crypto. I (58899) ovms-server-v2: Shared secret key is QTjRAp8ZQPJQV1UXnepldQpwLSijW/3qAZ6z0LOBHbGS (44 bytes) I (58899) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established OVMS > I (59189) ovms-server-v2: Incoming Msg: MP-0 Z4 I (59189) ovms-server-v2: One or more peers have connected I (59339) ovms-server-v2: Send MP-0 S87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0

6 72

OVMS Hardware v3.1
by Mark Webb-Johnson 30 Jan '18

30 Jan '18

Production… Analog Lamb, while interesting, is just (a) too expensive (double the price), (b) unproven, (c) uncertified, and (d) has long lead times. Using proven Espressif certified modules seems the safer way to go. So, we’ve decided to go with a switch to a standard certified ESP WROVER module, and external 16MB flash memory. The circuit board footprint for this is a little larger than the WROOM-32 module we’ve been using, and requires one more 3.3V->1.8V power conversion, but seems the safest way to go. Accordingly, I’ve agreed with the China guys to proceed along these lines for the main board: Change WROOM-32 to WROVER (on circuit antenna version, similar to WROOM-32). We can free IO12 (SD_D2), IO13 (SD_D3), and IO4 (SD_D1), by using just 1-line SDCARD. I don’t really want to use IO12 as that is a bootstrapping pin. WROVER PSRAM uses IO16 and IO17, so we can’t use that for modem. Move modem to IO4 and IO13. Change to 1.8V 16MB flash chip (W25Q128FW?). As SDD_VDIO is not exposed, add a simple regulator 3.3V->1.8V for external flash? When burning e-fuses, need to take care with 1.8V/3.3V SDD_SDIO fuse - leave at 1.8V. Add capacitors for SD CARD and external Flash, as per Espressif example. Increase size of solder pad for big capacitors, and USB connector, to make it stronger. For the data lines of circuit traces SDCARD, SPI bus, external flash, take care to keep away from power traces or other sources of interference and keep the traces as short as possible. The change to WROVER is a PITA at this stage, but that 4MB PSRAM should give us more headroom and the extra bill-of-materials costs is just a couple of US$. For the modem, we’re double-checking the power (which seems ok, but check to be sure), and changing passive -> active antenna. At the moment, it seems to be just a couple of passive components soldered inline between two easily accessible points. For existing developer modems in the field, we’ll try to make a simple upgrade kit (passive->active) for GPS, and post them out. If you don’t need GPS (such as Roadster users), the modem boards are functionally the same as the production ones. Existing developer OVMS v3 boards (with WROOM-32 module) will continue to be called v3.0. New production OVMS v3 boards (with WROVER module) will be called v3.1. We have conditional compilation in the firmware, to switch the pin assignments and whatever else is required. Branch: refs/heads/for-v3.0 Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3> Commit: 9504df70be78b6626970ec0ea53d2c2470e90afa https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/950… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/950…> Author: Mark Webb-Johnson <mark(a)webb-johnson.net <mailto:mark@webb-johnson.net>> Date: 2018-01-10 (Wed, 10 Jan 2018) Changed paths: M vehicle/OVMS.V3/main/Kconfig M vehicle/OVMS.V3/main/ovms_peripherals.h Log Message: ----------- Support for OVMS hardware v3.1 Converting developer v3.0 boards to v3.1 is not really feasible (a skilled solderer could probably use a 16MB Analog Lamb WROOM-32+PSRAM module; that would be a relatively simple de-solder + re-solder of the module, a not-so-simple re-arrange of the traces for IO16->IO4 and IO17->IO13, and disabling of external 16MB flash). Anyway, those existing developer modules should be fine to continue to use (just without the extra PSRAM). We are today finalising the circuit schematic and board layout for the above, and building a couple of test boards (with WROVER modules). I should have one in about a week’s time (assuming all the components are available). In that time, we’ll finish the ESP IDF v3.0 support, and test late next week / over next weekend (20th/21st Jan). Assuming no problems, we should be able to give factory the go-ahead to produce early the week after. Given that timing, I doubt if we are going to be able to get these boards made before the Chinese New Year holidays. Even if we can get them made, FastTech distribution may not be able to get them out during the holidays. Manufacturing in China starts to close down around the end of January / early February this year. New Year itself is mid-February. Anyway, we’ll get this all finalised, payment and instruction to start manufacturing in place, then do the best we can and get these out available during February. A big warning is going to go with them that this is for early adopters only, and firmware is changing on a daily basis. Updating firmware via wifi / sd card should be fine. I’m seeing a light at the end of a long dark tunnel. Regards, Mark.

3 8

Web frontend
by Michael Balzer 30 Jan '18

30 Jan '18

A first usable web frontend version is now in the hub. There are two new mongoose config options to enable serving from file space and list directory contents. I recommend enabling them, if you want to exclude access to the filesystem, you can do so by configuration params "http.server": // "http.server"Instances: // Name Default Function // enable.files yes Enable file serving from docroot // enable.dirlist yes Enable directory listings // docroot /sd File server document root // auth.domain ovms Default auth domain (digest realm) // auth.file .htpasswd Per directory auth file (Note: no inheritance from parent dir!) // auth.global yes Use global auth for files (user "admin", module password) File access is not needed for the web frontend though, just an option to be able to access i.e. CAN logs. The docroot can be set to "/store", but I don't recommend that. The config path is protected, but this relies on mongoose delivering correct paths -- a bug would open access to the config. If you want to serve from /store, use a sub directory like "/store/www" as the docroot. Global and web session authentication is bound to the module password (config set password module "…"). The frontend is AJAX based using Bootstrap & jQuery, with currently a very basic (functional) design. I've implemented a first home & status screen (just command outputs), a simple shell and config pages for the password and the basic vehicle setup (just type & id for now). I'll add config pages for wifi, modem, server & ota during the next days. The frontend is usable on a small screen, just the shell could need full screen support -- I'll have a look at that later on. The framework provides a page registration and page context utilities to enable custom / vehicle specific extensions with few effort. I'll add an example / template for this. Feedback is welcome. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 11

Um... what just broke?
by Greg D. 25 Jan '18

25 Jan '18

Hi folks, I just noticed I was one commit behind, so did a fetch and make app-flash. No joy... What broke? (and, how to fix?) Greg greg@linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> make app-flash Flashing app to serial port /dev/ttyUSB0, offset 0x10000... esptool.py v2.1 Traceback (most recent call last): File "/home/greg/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2524, in <module> _main() File "/home/greg/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2517, in _main main() File "/home/greg/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2246, in main esp = chip_class(args.port, initial_baud) File "/home/greg/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 177, in __init__ self._port = serial.serial_for_url(port) File "/usr/lib/python2.7/site-packages/serial/__init__.py", line 88, in serial_for_url instance.open() File "/usr/lib/python2.7/site-packages/serial/serialposix.py", line 268, in open raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg)) serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0' make: *** [/home/greg/esp/esp-idf/components/esptool_py/Makefile.projbuild:62: app-flash] Error 1 greg@linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3>

1 1

What is the format of ms_v_charge_timerstart?
by Geir Øyvind Vælidalo 23 Jan '18

23 Jan '18

Hi, What is the format of ms_v_charge_timerstart? I can’t find any info about it anywhere... Best regards, Geir

3 5

SPIFFS or FAT for /store
by Mark Webb-Johnson 23 Jan '18

23 Jan '18

ESP IDF 2.1 only had FAT support as a filesystem. We used this for the /store vfs mount, for config and script storage. ESP IDF 3.x now has SPIFFS as an option. SPIFFS is obviously more suited to embedded flash. What do people think about making the switch to SPIFFS for /store now? Doing so would probably not be hard (just a few lines of code change in the mounting of that /store partition), but would lose all config and script data in that partition (developers would have to disable vfs protection in menuconfig, then scp out first, to backup). Doing it later is not really an option. Thoughts? Mark

5 8

Transition to new esp-idf
by Stephen Casner 22 Jan '18

22 Jan '18

We expect production OVMS to be based on release/v3.1 of esp-idf in order to incorporate the support for SPIRAM (PSRAM). I'd like to set a target for all develpers to move to the master branch of openvehicles/esp-idf that contains the finished version of my modifications to support the "module memory" command. At the same time I need to then merge the corresponding changes from my temporary branch in openvehicles/Open-Vehicle-Monitoring-System-3 to the master branch there since the API between the two has changed. In other words, we need a flag day. -- Steve

5 46