It is possible to watch the runtime data of an ECU in several VemsTune, running on different PC-s.
- Easy over a LAN
- also possible via WAN (PC are possibly on different continents, behind firewalls), by starting a simple ("socat" relay) program near the master listening VemsTune (on same PC, or other PC in same LAN that can connect to the listening VT).
Marcell wrote a simple, but secure and high-throughput "rendezvous" server (called dragon) program that runs on a "real" internet IP (or configurable DNAT) and relays packets between master and slave VT programs, even if all VT are behind NAT firewalls.
- Off-the-shelf tool "socat" was used earlier, but involved multiple TCP ports, keeping track of TCP ports was left to the users
- 1 dragon process on the server services a practically arbitrary (currently limited to 15 VT slaves for each VT master), only 2 TCP ports needed regardless of the number of slave VT-s. Above topology shows dragon relay 1 and 2, but they are inside 1 process
- windows lacks basic networking tools like [socat] (or even netcat nc), but recently [socat windows compile is available] ... Download that.
VemsTune Master side setup
- after setting VT preferences: multicast mode, listen mode, port 9000 => restart VT
- Choose M: an odd port between 8801 and 8811, say M=8801:\nÿ1ÿ
- assuming sh... Anyone, what is the .bat version of this ?
- start 1 or more instances of this (N to be able to service upto N VT clients ... on any continents).
- advertise TCP PORT M-1 to your friend(s), to connect to. In this case: svn.x-dsl.hu:8800
client VT needs nothing special
- just Preferences / Communication: connect with TCP to svn.x-dsl.hu TCP PORT 8800
- or 8802, 8804, 8806, 8808, 8810 as agreed/advertised by the VemsTune Master: in this excample, 8800=M-1 assuming Master connects to port M=8801
- or the LAN IP : Port of the master in simple cases (if the network allows, that the socat relay is NOT necessary: the right side of the diagram above)
- NOTE: Preferences / Internet: Multicast=OFF (default). The TCP / IP address and port of the master is NOT to be entered under Multicast (no effect if OFF, anyway), but via the good old Preferences / Communication: (which predates the Multicast mode by years, and) theoretically older VT can be slave if fw is older. In practice ancient VTs are seldom used since VT (and fetched ini) needs to be newer than firmware for proper operation regardless of the connection mode/distance.
VemsTune has a special experimental "multicast-server" mode, which allows multiple client VemsTunes to connect (over LAN or WAN) in "view-only" mode (no changes allowed from those).
- Eg. while 1 VemsTune is used for tuning, 5 others (=tuning party) might be watching over the internet
- or some VemsTune-s running on local PC from different install directory; perhaps useful for multiple view modes, or to utilize a 4-core PC
- realtime data or logviewer (since 2014-11-xx logviewer is very fast with new firmwares >=1.2.23). The network penalty is minimal (~1.6 kbyte / sec for each client vemstune with 5-10Hz refresh-rate), and much more responsive than tight-vnc solution (especially if more than 1 watching).
Can we improve on this so that vemstune in the car connects to a master server, the master server is behind a NAT that has ports opened, this way the comms is established, the master and in-car vemstune can both adjust the config.
There is so much remote tuning going on now I feel this is required and a good way, the master could also remote log for the customer even if the tuner is not at the master computer for later reviewing. so the log is saves in the /vems_files on the master server just like when the ecu is normally connected.
Yes, this is along the lines we've been thinking as well. VT supports this (only 1 VT can "write confchanges to ECU" but that VT can be anywhere in the world). The issues are environment robustness and configuration, mostly:
- are the users able to "open NAT ports" in a car environment ?
- With modern 3G and 4G connections and GSM setups NO is the general answer, so should not be considered possible. Most GSM phones recide on a internal network of the carrier to save on IP addresses
- are the GSM channels robust enough so data (min 4 kbyte / sec / direction) can travel back and forth without seconds of blackouts ?
- 3G / 4G can support teamviwer which is much higher bandwith so data stream only should be easier on the connection.
- are the users able to diagnose what is going on when blackouts are experienced (if it's NAT, or GSM, or VT, or serialport or ECU issue ?)
- A ping could be implemented to keep track of internet connection easy, VT could also apply another hearbeat style connection between VT's, both VT's can report on which heartbeat is lost for instance.
- Experiments showed it's sometimes far from trivial (or no simple rules to tell easily). So: what tools can we provide to help diagnosis ?
To open connections between 2 devices behind NAT, we experienced with UDP "port birthday-paradox-rendezvous" (and some STUN-like service) and had some success, but for many GSM (and some DSL) it didn't work, or was rather unreliable for production.
- We found that we do NOT want to reimplement ICE from scratch
- webrtc had a major improvement this year (even basic examples did not reliably work a few months ago, now they are pretty good).
- I would say that the tuner/remote VT needs to be behind a NAT with open ports as a requirement. Makes everything alot more simple.
- so webrtc data "side-channel" could be used to feed/relay masterVT-ECU and masterVT-slaveVT, and advantage would be extra chat and voice and video for no extra effort
- but do we want to have a browser in the tuning path ?
- or use the browserless native API ? (which has other maintenance issues).