VCDS Mobile email notification this morning...

bhtooefr

TDIClub Enthusiast, ToofTek Inventor
Joined
Oct 16, 2005
Location
Newark, OH
TDI
None
In many cases, the phone is on the same subnet as any devices that connect to it as a hotspot. So, you can access things properly.
 

bhtooefr

TDIClub Enthusiast, ToofTek Inventor
Joined
Oct 16, 2005
Location
Newark, OH
TDI
None
You assume a phone's only capable of being on one network at a time.

When a hotspot is active on my Nexus 5 (or any Android device AFAIK), there are two network interfaces active - the cellular interface, and wlan0. The phone is acting as a router between the cellular interface and wlan0, but it has an IP and acts as a peer on wlan0 as well, and software running on the phone can communicate with any host connected to the hotspot.
 

bhtooefr

TDIClub Enthusiast, ToofTek Inventor
Joined
Oct 16, 2005
Location
Newark, OH
TDI
None
No sorry it's not any assumption I use HEX-NET daily. Also I've played with this idea long before but it's just not possible. When your device creates a hotspot it is creating a gateway between the 3G/4G and your WIFI radio. So it just can connect to that same wifi.
Exactly, and your phone when you open a browser it would be using the WWAN (cellular data), to access the internet.
Are you able to connect your browser to anything but the cellular data network when you have a hotspot active? If so pls show me how you are able to do so?
The browser isn't accessing the internet, it's accessing the TCP/IP stack. When you enter a URL, it looks up what IP address it goes to via DNS (unless you just entered an IP address directly), and then requests that IP address from the TCP/IP stack. (I am oversimplifying this ever so slightly, but you get the idea.)

The TCP/IP stack looks at what all it's connected to - this includes a hotspot that it's running - and sees where that IP address is. If it's one on the public internet, it sends it to the WWAN interface. If it's one on the hotspot, it sends it to the WLAN.

I'll demonstrate this with a test tonight.
 

tadawson

Veteran Member
Joined
Jun 14, 2013
Location
Lewisville, TX
TDI
2013 Passat TDI SEL, 2015 Passat TDI SEL
As bhtooefr said above, browsers do not (actually can not) bind to any specific network interface - they open a port to the IP stack which then uses the devices routing tables to determine which interface/network to use, and the browser has no visibility or control of this. This can be easily demonstrated on a computer with both a wired and wireless connection - switch connectivity with the browser open, and all works. Fee free to argue, but you will be arguing with the specifications fotr TCP/IP, which will be an uphill fight. Not to say that there have never been odd or non-compliant implementations (Windows, for example, could not concurrently run two network interfaces at the same time at one point . . . But *nix based platforms (including Android) have never has this limitation, and I have no idea on iWhatever, but suspect the OSX stuff to befine, since it's a *nix platform, and no clue on iOs)).

- Tim
 

bhtooefr

TDIClub Enthusiast, ToofTek Inventor
Joined
Oct 16, 2005
Location
Newark, OH
TDI
None
iOS is a full BSD/Darwin implementation with a dumbed down GUI on top.

Android is a Linux (although not GNU/Linux) implementation with a virtual machine on top.

Both of these are Unix-like, and in a networking sense, behave essentially like full computers running those operating systems.
 

tadawson

Veteran Member
Joined
Jun 14, 2013
Location
Lewisville, TX
TDI
2013 Passat TDI SEL, 2015 Passat TDI SEL
The context here is only mobile devices and browsers (i.e. Android, iOS etc etc) this is of no interest w/a full computer as it then isn't relevant with the HEX-NET.
Android runs on a Linux kernel, the same as any desktop, so your comment it without merit, sorry . . . Just because it's in a phone doesn't change the IP stack in the kernel.

- Tim
 

Santos_V

Ross-Tech AssociateVendor
Joined
Feb 13, 2006
Location
Lansdale, Pa
If you're able to create a WIFI HOTSPOT with a mobile device and connect the same device's browser to the same network (call it whatever you want) please show me how and with what device you are able to do so.
I've done this with iPhone 4, 5 and nexus 5.

These phones under tether mode act as the hotspot and can access local addresses (in this case, the hex-net).

There is no need for a third device to view the local address.
 

Uwe

Vendor , w/Business number
Joined
Feb 24, 2000
Location
Lansdale, PA, USA
G3TDI, some of the stuff you posted earlier is just plain wrong, and others have explained why. Also Santos has has done exactly what you seem to think can't be done, as have others. If you have a HEX-NET and you're having trouble making the same thing happen, come on over to our forum and we'll be happy to help you there.

-Uwe-
 

G3TDI

Veteran Member
Joined
Jan 19, 2011
Location
CA
TDI
1994 Golf TDI http://forums.tdiclub.com/showthread.php?t=305898
G3TDI, some of the stuff you posted earlier is just plain wrong, and others have explained why. Also Santos has has done exactly what you seem to think can't be done, as have others. If you have a HEX-NET and you're having trouble making the same thing happen, come on over to our forum and we'll be happy to help you there.

-Uwe-

Ok I just tested and yes indeed I am totally wrong, I tried to ask about this on your forums and got the impression from your reply that the only way was with a third (or second) device.

Well then. Good I was completely totally wrong which changes my attitude to the product a lot ;)
 

G3TDI

Veteran Member
Joined
Jan 19, 2011
Location
CA
TDI
1994 Golf TDI http://forums.tdiclub.com/showthread.php?t=305898
I've done this with iPhone 4, 5 and nexus 5.
These phones under tether mode act as the hotspot and can access local addresses (in this case, the hex-net).
There is no need for a third device to view the local address.
Yep just tried and works just used the app fing to find the IP and bingo! Thanks

Sorry guys I knew I should have not said anything on this lol but I was totally convinced it was the way I thought but hey I'm glad to be wrong since it simplifies life a lot with using the hexnet :)
 

tadawson

Veteran Member
Joined
Jun 14, 2013
Location
Lewisville, TX
TDI
2013 Passat TDI SEL, 2015 Passat TDI SEL
What kind of product is that (in general terms)?

VCDS-Mobile is a scan tool, where the modules in the car are generally the limiting factor in performance and throughput. Unless of course you're using VW's own scan-tool (which Windows-based, but serious bloatware). Ours make theirs look bad that way. :D


Depends on what you consider "fail". Have you tried making a BT scan tool that works iPhones or iPads? Like 'em or not, they're a big (and relatively loyal) segment of the mobile device market.


.... you have a totally different perspective than I do as small business owner. I think I understand yours, because I spent 10 years in such an environment. I'm not sure you understand mine, including the part that we're awfully tired of having our work stolen...


So tell me, if I gave you $1 million and told you I wanted you to develop a scan tool for brand X cars, and I wanted it to be usable on ANY mobile device, no matter what the OS, present or future, as well as any real computer made in the last 5 years, no matter what the CPU architecture, OS, etc, what tool(s) would you use? I'm just curious.


Why thank you!


No, grabbing a Windows box is the alternative if you have no connectivity, and you need functionality that isn't available in the product stand-alone mode. We believe that once the VCDS-Mobile is mature, the need to resort to "VCDS Classic" will be exceedingly rare.


How does it make sense to add a display and make this a stand-alone device when everyone already has perfectly good display in their pocket? How many people would pay for that?

-Uwe-
Uwe -

Sorry for the slow reply to this - it's been a heck of a week, and I also wanted to do a little research first . . .

Firstly, out product is an enterprise storage array, based on a grid archetecture - and hence, a similar need to lob commands as multiple processors, with somewhat critical timing. We also collect realtime responses to determine go/no-go on subsequent commands, and hence need close coupling to the device. Realtime statistics can also be plotted.

I appreciate the need/desire to support Apple devices, but it's kinda sad when a development direction needs to be made based on a certain vendors consistent attempts to avoid supporting standards, or standards correctly/fully . . . but it is what it is.

I understand the need to have your code protected, but I would have to think that there is risk in anything - if it can put put on a device and sold, then likely someone can pull it back as well. Heck, with the size of EAROM/PROM technology these days, you could always load the actual operating code on the dongle in an encrypted form, protected by a device license or some such, and upload/decrypt/run on demand, and the code on the device in question would be some lean device to pull into memory/decrypt/run . . . Nothing is perfect, but perhaps this would make it hard enough to attempt to recover that theives would give up, and likely just as hard as reading the image in the dedicated device, but that's only speculation, since I obviously don't know what safeguards you have in place. Also locking to a dongle (which you appear to do now) I would think would provide a reasonable level of protection, but might again require a registration key so that the world doesn't end up with "Dongle#X" out there 25,000 times . . .

I think it's clear that the ultimate goal really for any software house is the lowest effort possible to support the most users possible without getting totally ripped off, and to provide quality while doing it. I see the difference in the small business is that you can't afford to pursue remedies via the law, and you are too small for the government to really give a damn, which is sad . . . .

If you gave me $1million to develop something like this, I guess it would depend on what was a given. I am taking this to mean the UI issues, and will assume that the protocol to speak to the car is a known, since I think that would be the hard part if starting "clean sheet". Assuming that is known, then the decision comes down to what is available cross platform, and a bit of looking shows me at least two decent candidates that are so well deployed that I think stability is pretty much as good as it gets, and those would be Qt or Java. I'm not a fan of Java, due to all the bloat and other issues, but it does work, and has been used for a lot of stuff with similar (or greater) levels of functionality to VCDS. Qt is also interesting in that it supports, based on my research, Apple OSX, Apple IOS, Android, *nix, and Windows . . . and is distributed open source, so if there are any future issues, you have the choice to carry support forward as you choose, if desired. Having said that, either of these will give you a consistent UI interface on all platforms, and considering that VCDS pretty much has it's own "look and feel", the lack of similarity to the base platform gui really isn't an issue, since it's not there now. This is largely a toolkit based on standard C++, so I would write the logical part of the code is native C++, since it is not hardware dependent, I would modularize the comm functions (opening a USB device in this case, which should have some consistency across platforms, but platform #ifdef code block to handle the diffs may been needed), and handle the UI design/implementation via the Qt toolkit and the UIC User Interface Compiler, which allows a consistent UI definition via XML that will be compiled by the kit to whatever platform is targeted.

As long as you stick with standards compatible code, I would think that the C++ would be good almost forever, any changes to comm will be minimal at best, and Qt will handle the graphic stuff for you moving forward.

About the only risk would be if a vendor decided to do a full "rip and replace" of a primary graphic system for something totally different, and then you have the same situation you have now - hard to plan for a platform provider doing something radical/stupid . . . In which case the solution is similar to what it is now - wait for appropriate support, and hope your clients are not blind lemmings who charge at anything new without first considering ramifications. Having said that, though, I have a *LOT* of Qt stuff running (it's extremely common on *nix platforms) and have had very, very few issues with something not working moving forward - there is no 1:1 code to version compatibility lock-in, most stuff will work find with a newer toolkit.

The only remaining issue I see, is that while this lets you run the same codebase on pretty much all platforms out there that are currently desired (as well as a few that some of us would like to see supported, which have not been discussed), is the issue of "Is the "normal" UI appropriate on all devices?" and I suspect that the answer will be a resounding "No!". What works on a large desktop screen vs what works on a laptop vs tablet and then phone is not the same. Most phones have such small screens that I would think that a different UI would almost be mandatory to deal with the small screen real estate, and tablets would be pretty marginal at best in a lot of cases. Fortunately, the current look of VCDS is not that "busy" or crowded on most screens I have seen, so hopefully, this would not be a huge issue, but there may need to be some runtime conditionals as well to handle the different devices that might run the same build, or perhaps user settings to adapt the UI to the users eyes/desires.

And my point about adding a display is that then it is *ONE* device that has no compat issues - grab it and it *WILL* work . . . yeah, everyone has a display device, but it can be a bit of a pain to have to carry multiple devices out to work on the car, and there are some really nice color touch devices out there for pretty low $$$ (some for the Raspberry Pi for about $40, a bit small, but still bigger than a lot of phones screens . . . ). And then you own the whole damn thing, and have *ZERO* issues with interface/compat to external devices . . . and a lot harder to leave the dongle/device is someones car in error too!.

I'm sure some segment of this thread will start whining and bleating that I am continuing this discussion, and frankly, I don't want to hear it. Uwe asked me a specific set of questions which I felt were part of a very good intellectual dialog, and I choose to respond to those questions. If you don't like it, feel free to avoid my posts . . .

- Tim
 
Last edited:

MonsterTDI09

TDIClub Enthusiast, Veteran Member
Joined
Jul 3, 2009
Location
NoVa/NJ
TDI
2010 Jetta DSG/ up keep on 2009 Jetta DSG 2006 Jetta Pag 2 in North SEA Green
I just think you start another thread Tim.
 

1dieselsteve

Veteran Member
Joined
Apr 10, 2013
Location
Marinette, Wisconsin
TDI
2010 TDI Jetta
Ok... Talked to Ross tech the other day about some cables. Guess gonna stay away from the wifi since they are fairly new. Now I'm thinking I'm going to buy the vcds license with hex-USB+can all vag $349 vs. the micro can for $249. Don't wanna end up not having the wrong one later or all of the sudden not working with the car I have or my gf getting
 

burpod

teh stallionz!!1
Joined
Nov 27, 2004
Location
cape cod, ma
TDI
82 rabbit vnt ahu, 98 jetta vnt ahu, 05 parts car, 88 scirocco.. :/
why not buy someone's used cable, since many people are getting the hex-net. i recently just sold my perfectly working genuine ross-tech cable for $160 shipped to fund my hex-net purchase :)
 

romad

Top Post Dawg
Joined
May 27, 2011
Location
Prescott, AZ
TDI
2005 Jetta GLS Wagon "Cranberry"
why not buy someone's used cable, since many people are getting the hex-net. i recently just sold my perfectly working genuine ross-tech cable for $160 shipped to fund my hex-net purchase :)
Does that transfer the VCDS license with it?
 

JSWTDI09

Top Post Dawg
Joined
Jan 31, 2009
Location
Las Vegas, Nevada
TDI
2009 JSW TDI (gone but not forgotten)
Does that transfer the VCDS license with it?
It does transfer the license (the license is in the cable). What it doesn't transfer is the registration. The registration is necessary for direct help from Ross-Tech and for most upgrade offers (interface upgrades). It is not necessary for software updates. If you don't need Ross-Tech's help a used cable will work fine.

Have Fun!

Don
 

romad

Top Post Dawg
Joined
May 27, 2011
Location
Prescott, AZ
TDI
2005 Jetta GLS Wagon "Cranberry"
It does transfer the license (the license is in the cable). What it doesn't transfer is the registration. The registration is necessary for direct help from Ross-Tech and for most upgrade offers (interface upgrades). It is not necessary for software updates. If you don't need Ross-Tech's help a used cable will work fine.

Have Fun!

Don
OK, so how would the new owner of a used cable get the VCDS software installed on his Windows computer? Connect the cable to it and copy the application?
 

burpod

teh stallionz!!1
Joined
Nov 27, 2004
Location
cape cod, ma
TDI
82 rabbit vnt ahu, 98 jetta vnt ahu, 05 parts car, 88 scirocco.. :/
as don said, the "registration" is only for direct help from ross-tech. if it's a genuine cable, there is nothing to do. you can download the vcds software on multiple computers anyways. it doesn't know if it's "you" that is using it. so you can buy a used genuine cable and download the vcds software no problem
 

JSWTDI09

Top Post Dawg
Joined
Jan 31, 2009
Location
Las Vegas, Nevada
TDI
2009 JSW TDI (gone but not forgotten)
OK, so how would the new owner of a used cable get the VCDS software installed on his Windows computer? Connect the cable to it and copy the application?
You just download the program and install it. The first time you run the program, you have to plug in the cable and plug it into a car. Then you have to go to the "options" screen and "test" your cable. This reads the dongle in the cable, and tests the car's connection. Then you can change screen size (or any other options) and then save the configuration. Once this is done (the configuration saved), you just plug into a car and run the program. If you do not connect to a car the first time you run the program, it will nag you every time you run the program until you do this "test" and "save" from the options screen. You have to do this test and save thing every time you install the program - a minor PITA.

Have Fun!

Don
 

burpod

teh stallionz!!1
Joined
Nov 27, 2004
Location
cape cod, ma
TDI
82 rabbit vnt ahu, 98 jetta vnt ahu, 05 parts car, 88 scirocco.. :/
just quickly... but i finally got my hexnet working. connected to the cloud, vcds over cable, and vcds-mobile both on my windows XP laptop and in ubuntu with virtualbox running windows XP :D

the one last thing i'm confused on how to do is to use VCDS (proper) over the net, which i heard was possible. hopefully some better documentation for this whole process of installing hexnet will be available. it was a bit of a struggle for me to figure it all out (with big help from tdichat!), although that is partly my fault as i can be a bit dense sometimes...
 
Last edited:
Top