Android Question WiFi Direct Issue

[Harris]

I have a situation where many mobile devices are travelling up and down a road where they cross each others path. I need to determine what the vehicle speed is when they are in (very) close proximity. The Bluetooth channel has already been dedicated to another device so I would like to use WiFi direct. No one device can act as server since it may be miles away from all other devices.

Playing with the Wifi direct example and lib, it seems that one device must act as server and the other(s) as client. In my case, upon discovery, each device must act as both (I assume). Each unit comes in and out of range of the other and I need to know what the speed is of each unit - and communicate this.

The question is: can I set each device as a server and connect to the other, exchange data, or connect each device as a client, exchange data - OR must one be a server and the other(s) be a client (tear down and build up these connections on the fly and make it work)? At anytime. neither is a client or a server since they are constantly passing in and out of each others range (who is what?).

I was hoping this process was like a two-way radio, where each could communicate upon simple discovery of each other.

Signed stuck.

Thanks

 

[Erel]

See the Wifi direct example: https://www.b4x.com/android/forum/threads/android-wifi-direct-tutorial.30409/#content

Both devices can act as a server or a client. When the Wifi Direct connection is made one of the devices will have an ip address of 127.0.0.1. In the example this is the one that acts as a server.

Once there is a TCP connection then it no longer matters whether a device is a server or a client.

 

[BillMeyer]

I have a situation where many mobile devices are travelling up and down a road where they cross each others path. I need to determine what the vehicle speed is when they are in (very) close proximity. The Bluetooth channel has already been dedicated to another device so I would like to use WiFi direct. No one device can act as server since it may be miles away from all other devices.

Playing with the Wifi direct example and lib, it seems that one device must act as server and the other(s) as client. In my case, upon discovery, each device must act as both (I assume). Each unit comes in and out of range of the other and I need to know what the speed is of each unit - and communicate this.

The question is: can I set each device as a server and connect to the other, exchange data, or connect each device as a client, exchange data - OR must one be a server and the other(s) be a client (tear down and build up these connections on the fly and make it work)? At anytime. neither is a client or a server since they are constantly passing in and out of each others range (who is what?).

I was hoping this process was like a two-way radio, where each could communicate upon simple discovery of each other.

Signed stuck.

Thanks

This sounds like a very interesting project and I would ask the following questions:

1. At what speeds do these vehicles travel ?
2. Is there enough time to connect and exchange data ?
3. Is there enough range on the WiFi to detect in time and then connect and then exchange data ?

The reason I'm asking is that my device to my router has about a 30m range and given a vehicle travelling at 100kms per hour they will need to "see" each other, connect, exchange and disconnect in about a second. On the other hand, if they were both travelling in the same direction this would not be a problem, I presume.

If your project is not propriety and has no secrets, share some of your design ideas - this would be interesting to hear and we could perhaps exchange some.

 

[Erel]

My guess is that Wifi Direct will not work fast enough for this scenario. Can't you use an online server and let all vehicles connect to it?

 

[BillMeyer]

I agree Erel.

What I would do is the following: (Just sharing - not imposing)

1. Set up a central backend server with NoSQL or MySQL on it.

2. Map the route and place the lat/lon on the server as a reference. This would be to create bounds for the "vehicle devices" to operate in - otherwise you have a consistent checking and drain on the battery - even if you are not on the route. Make use of the Geo Fencing examples here on the Forum to bound the route and create a type of virtual corridor.

3. After checking that the vehicle is on the route, get each vehicle to send it's location to the server every x seconds or minutes, initially with an Insert and there after with an Update. Using the Speed keyword on the Location Lib to place it's speed in the db as well and possible the Heading/Bearing.

4. Using the Haversine Formula or the DistanceTo keyword in the Location library find what vehicle is within a certain distance from you, identify it and relay the information to the user on screen or via TTS via BlueTooth over the vehicles Stereo system - Safety is at all times of the UTMOST IMPORTANCE !! (Eyes on the Road)

5. Switch Off your System. If the system is no longer relevant for reasons of the user not being on the route anymore you would need to geo fence all the exits and once the person has entered this Geo fence - switch off the system, but use the Service StartAt to periodically check if the user has re-entered the route.

Caveats:

Haversine and DistanceTo will give you the distance to the object in a STRAIGHT line - so the other vehicle could be in front, to the side or behind you. If you want to bring in more features, then I presume one could use the Bearing Keyword and a few If/Case statements.

On a route that is longer than a few kilometres/miles you might have to create a few Geo Fences - especially given curvature, bends and the likes on the route making circular Geo Fences difficult to implement - polygons might be the in thing here (Examples on this forum as well).

Effective GeoFences are about 100m in radius - 50m with a push - so this gives you another set of problems - especially on exits to the route.

Just my 2 cents - enjoy !!

 

[Harris]

Interesting...

This project involves vehicles travelling on a single private road (52 miles long) in the extreme remoteness of North Alaska. There are no cell towers to connect to for real time data transfers. The only wifi access is near the shop where data is downloaded at the end of a work shift.

I currently capture data for each second of the trip gathering many parameters (speed. rpm, lat/lon, etc). I have created an algorithm where I process the data and based on small geo-zones to determine if two or more vehicles are in a zone at the (near) same time.

The max speed of any vehicle is 80 kph but more likely around 50 - 60 since they are heavily loaded (lead / zinc).
The whole purpose is to determine when vehicles pass each other, 1 going north - the other south, neither vehicle speed must not exceed 20 kph for safety reasons (narrow road, fog, snow, darkness, etc). The narrow window of when wifi-direct is available will satisfy the critical data required - at this crucial point. All I really need is each vehicle's speed, lat/lon and unit number when in this adhoc zone - especially when they are at the same lat/lon (beside each other). One vehicle, let's say the loaded one, can be responsible to get this data. Now I have a small subset to process (120 records for 3 minutes) rather than 86400 records (potentially using the other method - and much cpu load processing data).

I will play with the example more to see if I can make this happen.
More feedback is welcome now that you know my purpose.

It also appears that wifi is also up and running when direct is also enabled. This is nice since I should not have to fool with the connection to the AP at shift end to get data off device.

Thanks

 

[OliverA]

Source #1 relates to ranges for WiFi direct: (https://stackoverflow.com/a/24705722)
Source #2 relates to time taken for WiFi direct connection to be established: (https://stackoverflow.com/a/19297780)

@20Kph, you're looking at about 5.6 meters per second. Going with an optimistic 50 meter range for your WiFi (I'm assuming no external antenna, having to go through the truck walls, glass, etc), you have about 9 seconds worth of time. With a 4-6 second setup time for the WiFi connect, you may have 3-5 seconds worth of time. The issue is that even though a connection is established, it may still take even more time to discover that the connection has been established. Also, any other interference (truck walls, weather situation, other signals in the truck, etc.) would cut the distance and time allotted for the connection and data transfer to happen. Then you also need to take into account the WiFi ability of the device used. Would you be able to install external antennas on the trucks for WiFi and tie your devices to the antenna(s)? That may give you the additional distance needed to give you time enough to pull this off. Doubling the range would give you an additional 9 seconds to play with.

 

[Harris]

Source #1 relates to ranges for WiFi direct: (https://stackoverflow.com/a/24705722)
Source #2 relates to time taken for WiFi direct connection to be established: (https://stackoverflow.com/a/19297780)

@20Kph, you're looking at about 5.6 meters per second. Going with an optimistic 50 meter range for your WiFi (I'm assuming no external antenna, having to go through the truck walls, glass, etc), you have about 9 seconds worth of time. With a 4-6 second setup time for the WiFi connect, you may have 3-5 seconds worth of time. The issue is that even though a connection is established, it may still take even more time to discover that the connection has been established. Also, any other interference (truck walls, weather situation, other signals in the truck, etc.) would cut the distance and time allotted for the connection and data transfer to happen. Then you also need to take into account the WiFi ability of the device used. Would you be able to install external antennas on the trucks for WiFi and tie your devices to the antenna(s)? That may give you the additional distance needed to give you time enough to pull this off. Doubling the range would give you an additional 9 seconds to play with.

On my desk, connection is instant - because they are 1 foot away from each other... Each unit cresting a hill (on opposite ends) may be a different matter due to no line-of-sight.

Again, I have all the data needed to determine this but the process is long and involved, demanding high server CPU and a scheduled time. I am looking to shorten the process by real time capture using device hardware / functionality - Stretched to the limits.

Sorry, no additional antenna can be installed. The Samsung Active 8 tablet does not support this - no port (now obsolete - as many good products have become). That would have been nice since an external antenna would have increased the range.

I don't need much and not for long. The critical moment is when they pass each other (when strength is 99 percent). So, maybe have loaded trucks (going south) be the server and do the grunt work (collect data). Empty trucks would just need to be in a mode to see server and connect / transmit who they are, where they are and road speed.

The tablets are mounted so they are looking through the windshield. I connect to the AP, at shift end, and transmit daily data at distances of up to 200 meters away easily.
I could, I suppose, constantly buffer data to send as a large burst (10 k) - just as vehicles pass each other.
Or, lessen the transfer payload by having both vehicles store their own data and figure it out on the back end - by using a unique id that each shared during a passing event to sync the data. Like I stated in past posts - "Cat Skinning - there is more than one way..."

Granted, this may or may not work - but one will never know unless you experiment. I can do this in my own environment without having to be on-site to see if it is feasible.

Yes, it sucks not having real time over cell. All of this could have been avoided.
If I can get this to remotely work, it produces another benefit. I can advise drivers (pop up warning screen) of an approaching vehicle - even if they did not get the mandatory two-way radio message when they are suppose to call out.

Note: There has been many incidents when vehicles left the road, wrecked truck and trailers, caused expensive clean-ups (lead anyone?) and personal injuries because drivers did not slow down (or stop as sometimes required) when approaching an on-coming vehicle.

Thanks

 

[OliverA]

There has been many incidents when vehicles left the road, wrecked truck and trailers, caused expensive clean-ups (lead anyone?) and personal injuries because drivers did not slow down (or stop as sometimes required) when approaching an on-coming vehicle.

Could that justify the expense of a separate on-board (in-vehicle) router with external antennas (long range ones?). Even though, with the current data you have on connectivity, you may have the time needed for your data transfer. I think it's time for some testing! OT, more of a curiosity, would you be able to configure everything remotely?

 

[Harris]

The router cannot be hardwired to the device. It would need to be an AP accessed over wifi - wifi direct... More complications.
Let me test with what I have first.
Setting anything (updating apps and such ) is a bitch. SLow sat connection that often drops out before I get anything uploaded to their server.
Teck Resources has a huge IT dept yet try and get something simple done as a contractor... Geez-us...

 

[Harris]

Once there is a TCP connection then it no longer matters whether a device is a server or a client.

This is what trips me up.
Can client send to client? Can server send to server? Client CAN send to server and the other way around of course.
This is what is confusing. In the past we need a server and then a client. It seems you are stating that this is no longer the case.
I tried, with your example setting each as a client (no server) but I could not communicate.

I don't know who will register as 127.... since each is on the go (travelling towards each other) - or does that matter - can both be 127 (or is that the OTHER device IP this one is connecting to)?

The simple example (yours) works fine. First time I tried to connect, the damn permission dialog came up to accept connection. Hopefully Google fixed this with manifest declaration. Accepting this while driving is a no-no (distracted driving laws prohibit screwing with your device ).

Thanks

 

[DonManfred]

You should start the app permission request once before start driving
The Permission must be accepted by the user once. After that you´ll directly get an positive result event in the future....
Maybe in the options you´ll implement a initialization of this. The request is send, the user get the permission request, the user accept it, you get the result and go on...
Later in the app, when you need to activate this, you do the request when start driving too. But this time you immediatly get an result-event as the user already answered the permission request.

 

[Harris]

You should start the app permission request once before start driving

I restarted tablets after pairing. New discovery connection requests same permission dialog - which indicates the recent pairing was not stored on either device.
With 30 vehicles, each one trying to connect to any of the others will raise this - if not already connected and accepted during this session (after last reboot).
I don't think this is workable. Imagine driving down the haul road and a new vehicle appears within range and starts begging you to accept connection request? What a distraction when the driver is trying to focus on the danger immediately ahead. Too bad it won't let you define a range of ip's that are trusted and granted.

 

[Harris]

https://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html

Does this mean anything to anyone?

Thanks