- OvmsDev - Open Vehicles

Advice on mechanism for responsive ECU -> HUD.
by Michael Geddes 22 Feb '23

22 Feb '23

Hi all, Now that I have a functional HUD connection, I've been tweaking some things to make sure it is responsive. The HUD itself is polling multiple times (4?) per second, so it's making sure the speed (particularly) metric is kept up-to-date. Initially, it was really slow because I had left the message throttle as its default of 1. Which means that at most 1 ISOTP message was being executed a second and speed was being updated every 3-4 seconds, which was unusable. I upped that to 8, and that was an improvement, and now I have this sub-ticker mechanism (below) implemented, and it appears to increase responsiveness and decrease latency between the dashboard speedo and the HUD speedo. It's really hard to observe as it requires that you be driving! It's also hard to be objective. Without the sub-ticker it's workable. With the sub-ticker, I think it just tightens it up that much more. So I have implemented the following: a) I added a new ticker timer in 'housekeeping' which sends an event every 1 ms "ticker.ms.100". (Though I'm thinking that every 2ms might be sufficient). The message is blocked from being sent to the web (now). b) In vehicle.h I have a (protected) function PollSetSubtick(bool) that can turn off and on the use of this 'sub-second' ticker (first time it's turned on is when it actually registers for the event). This then sets up a count that is reset whenever the polling ticker is incremented (m_poll_ticker) and the sub-ticker is enabled. c) When enabled, from sub-ticker count 4 onwards every 2 sub-ticks (0.1s), it calls PollerSend(false) as long as 1) It hasn't reach the end of the list, and 2) we aren't waiting for more parts of the current ISOTP message. The idea of this is that it keeps the queue moving in case there were protocol errors or other hiccoughs that stopped it continuing! d) I have implemented events for when the ecu is turned on and off: vehicle.ecu.start and vehicle.ecu.stop respectively called from the constructor/destructor of the ECU class. e) For (currently) the Ioniq 5, I register a listener for these events and then call a function ECUStatusChange(bool). 1) For 'enabled' this calls PollSetThrottling(8) and PollSetSubtick(true) 2) For 'disabled' this calls PollSetThrottling(4) and PollSetSubtick(false) f) The other thing I did for Ioniq 5 was to put an extra 'Speed' check at the end of the poll list - (for car 'on' only). Which means it checks speed twice per poll tick. Any feedback on any of this would be greatly appreciated. I'm worried about * Thread safety (would these events be executed in the same thread?) * Overloading the system somehow / causing battery drain when system off. * Do I need to turn off the ticker.ms.100 event at some point for power-saving? When? * Stuff I haven't thought of. //.ichael Geddes

3 9

Using Ovms to display information on a HUD
by Michael Geddes 09 Feb '23

09 Feb '23

Hi all, Now that I have an OVMS board that can actually sustain the HUD display power (not sure what was wrong with the previous one), I've certainly been making some inroads and found having the HUD a useful tool. I've got the internal ECU running, although I had to add a script for RPM to get the absolute value since the HUD doesn't like -ve numbers! I'm not sure I need RPM, but at least I now know that I'm retrieving sane values... so that was quite useful. Interestingly at 100km/h, the RPM gets up to 7000 which the HUD doesn't expect and with alarms on, it engages the 'shift now' HUD alarm as well as the 'that's definitely too high an RPM' HUD alarm!!! lol. (I worked out how to turn the HUD alarms off). One of the issues I'm having is that the refresh rate is 1 every 3 to 4 seconds, even after I upped the POLL time entry for the Ioniq 5 OBDII messages that contain 'speed' and 'rpm' to be every 1 tick. I'm not sure how long it takes to complete receiving .. or how often '1 tick' is happening in reality, but I'm guessing that might be some of the problem. What do other people who have a HUD experience? The other problem is that the ECU seems to occasionally stop working/responding to HUD requests.. so I'm going to have to look at that. I don't even have file logging at the moment on the new OVMS.. but once I get that up and going again I may have some more data. I have noticed that the OVMS itself isn't resetting .. so it's not a system crash. Closing the ECU down along with the power using *power.off* event and starting them both up again on *power.on* certainly means I'm more likely to start off with it working! Any thoughts on diagnosis welcome. //.ichael

2 3

CAN bus logging not working
by Christos Oscar Kambiselis 08 Feb '23

08 Feb '23

Hi, Has anyone had any problems with CAN bus logging? I have a 32GB SD card installed and "SD status" gives: *SD CARD is inserted* *Status: available* *Name: SD32G* *Size: 30419 MB* *Free: 29767 MB* *Card type: SDHC/SDXC* *Max speed: 25000 kHz* *Capacity: 30436 MB* *CSD: ver=1; sector_size=512; capacity=62333952 read_bl_len=9* *SCR: sd_spec=2; bus_width=5* I have setup CAN1 and 2 to "listen" and started the logging like it's mentioned in the user guide, checked the status, I stopped it some time later, and when I go to open it from the Web UI it is empty, also tried from the Editor and it is also empty, removing the card is a bit tricky since the hardware is pretty tucked away in the console. I searched the manual for a format command but can't find anything. I do get messages and readings on the OVMS Android app, so at least the OBD CAN is fine. Oscar

3 7

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

Firmware release 3.3.003 to MAIN / 3.3.004 preparation
by Michael Balzer 16 Jan '23

16 Jan '23

We missed releasing 3.3.003 to /main. It's been in /eap since 09/22, /main still has 3.3.002 (since 03/22). Mark, would you please go ahead on this with api.openvehicles.com? I'll follow with ovms.dexters-web.de. Regarding 3.3.004: Thanks to all contributors we have three new vehicles in the queue: - Renault Zoe Phase 2 initial support by Carsten Schmiemann → https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/732 - Hyundai Ioniq 5 initial support by Michael Geddes → https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/762 - Mini Cooper SE initial support by Vincent Barat → https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/789 Michael Geddes has also done a lot of great work on implementing full user metrics unit support at the module. This already works very well and stable in the shell, and the web UI extension now is also ready for inclusion (Michael, unless you've got some open todo I missed?) → https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/795 To get the new vehicle support into /main ASAP, I suggest heading for the 3.3.004 release now, including Michael's user unit support. Please report any open issues that need to be addressed for the 3.3.004 release. Thanks & regards Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 5