Today I learned there are 115 Bluetooth data loggers on the Beltline

[Dougal]

http://host.madison.com/wsj/news/local/beltline-drivers-watched-from-helicopters-above-in-name-of-improving/article_0d2e3dfa-fdf1-11e1-980a-0019bb2963f4.html

[Anton Kapela]

Hrm, wonder what might happen if a few million random device MAC addrs appeared one day 

-Tk

On Sep 14, 2012, at 7:29 AM, Dougal <zelef...@gmail.com> wrote:

http://host.madison.com/wsj/news/local/beltline-drivers-watched-from-helicopters-above-in-name-of-improving/article_0d2e3dfa-fdf1-11e1-980a-0019bb2963f4.html

--
You received this message because you are subscribed to the Google Groups "Sector67 Public" group.
To post to this group, send email to sect...@googlegroups.com.
To unsubscribe from this group, send email to sector67+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sector67?hl=en.

[Markus Schumann]

$900,000 budget for figuring out:

Too many cars will lead to congestion.

--

Markus Schumann

+1 (608) 628 9600

[Dougal]

I encourage you in the vaguest possible terms to disrupt this system.

[Anton Kapela]

I foresee technical difficulties 

-Tk

[Anton Kapela]

NY dot studied this ages ago -- most efficient traffic eng constraints are known, but nobody likes them:

-everyone drives ~35 mph

-cars spaced ~6' apart 

This yields highest per-lane throughput,  lowest blocking and holding times at admission points (on ramp), but can easily flood egress points (off ramps), which themselves cannot drain enough average cars/sec to keep up. 

Time for closed loop centralized control plane. If we all still want single occupant cars at the lowest possible latency, that is, and want best utilization of the available paths, anyway. If we don't want that, then heh...I'll keep walking either way!

-Tk

[Dougal]

Also, the social norm that when faced with a lane reduction, drivers should merge as soon as possible also contributes to congestion. It's more efficient to wait until the last possible time to merge, otherwise you're making a virtual one-lane road when the road has two open.

[Nick Daly]

On Fri, Sep 14, 2012 at 8:21 AM, Dougal <zelef...@gmail.com> wrote:
> Also, the social norm that when faced with a lane reduction, drivers should
> merge as soon as possible also contributes to congestion. It's more
> efficient to wait until the last possible time to merge, otherwise you're
> making a virtual one-lane road when the road has two open.

That doesn't make sense unless the most important part is how long
each lane exists for. Once all cars are merged, they should be
driving at a constant pace, so how long each particular lane exists
shouldn't have anything to do with it. I'd find it easier to believe
that the merging itself caused the problem, because you're then
stopping both traffic lanes.

My money's on the people who keep switching lanes, to get around
stopped traffic, as the biggest slowdown. It seems like an ugly chain
reaction.

[Dougal]

Many studies have found that late merging decreases congestion in lane-reduction situations like construction zones, significantly. http://www.virginiadot.org/vtrc/main/online_reports/pdf/05-r6.pdf 

[Anton Kapela]

Nick's hinting at something big:

On Fri, Sep 14, 2012 at 8:56 AM, Nick Daly <nick....@gmail.com> wrote:

> My money's on the people who keep switching lanes, to get around
> stopped traffic, as the biggest slowdown. It seems like an ugly chain
> reaction.

cars on a highway are well modeld by a string of finite state automata
-- that is, each car is independently computing its control, taking
inputs from its surroundings independently, etc. So what's the problem
with that, "you're stating the obvious tony," etc?

The problem is: brake lights

You can send 'slow down' messages fromt he head of a mile-long train
of cars to the rearmost car in under 10 seconds, but you cannot send
'speed the f up!' the front the train.

-tk

[Dougal]

you cannot send
'speed the f up!' the front the train.

I object to this assertion. This is why I have a horn ;o)

[Anton Kapela]

On Fri, Sep 14, 2012 at 9:20 AM, Dougal <zelef...@gmail.com> wrote:
>> you cannot send
>> 'speed the f up!' the front the train.
>
>
> I object to this assertion. This is why I have a horn ;o)

i know your'e just lul'in, but FSA's are just doomed. centralized
control plane or bust.

-tk

[Alex McLees]

For anyone who likes to fiddle with the dials

[Peter Novotnak]

Tk, does it cost more oil to ride or to walk?

[Nick Daly]

On Fri, Sep 14, 2012 at 9:10 AM, Dougal <zelef...@gmail.com> wrote:
> Many studies have found that late merging decreases congestion in
> lane-reduction situations like construction zones, significantly.
> http://www.virginiadot.org/vtrc/main/online_reports/pdf/05-r6.pdf

That's interesting. I was actually thinking of the stop-and-go of
your standard traffic jam, where it would be lane jumpers that brought
all the lanes to a halt. Unfortunately, that's not the primary
context for this hypothetical argument.

I concede the (contextual) point :)

[Joe Kerman]

Im kind of wondering if Bluetooth users are representative enough of
the population to get a good sample set. <insert thinly veiled 1%'er
argument here>

[Anton Kapela]

i think any active, even not discoverable BT transceiver will
periodically poll for other BT stations (phy management layer does
this, iirc).

[Nick Daly]

But, is the population of folks with BT devices distributed evenly
throughout the traffic? If not, certain neighborhoods could
disproportionately influence the count.

It doesn't really matter what percentage of folks own BT devices, as
long as they're evenly distributed throughout the population.

[Anton Kapela]

On Fri, Sep 14, 2012 at 1:22 PM, Nick Daly <nick....@gmail.com> wrote:
> But, is the population of folks with BT devices distributed evenly
> throughout the traffic? If not, certain neighborhoods could
> disproportionately influence the count.
>
> It doesn't really matter what percentage of folks own BT devices, as
> long as they're evenly distributed throughout the population.

I'd wager that today this is going to pretty even -- even the most
spartan and simplistic clamshell phones would be visible
periodically... again, even if it's not an actively used feature,
anyone with so much as a pre-paid handset post 2006ish will have BT
included and active by default.

-tk

[Dougal]

I am bothered by your statement that my phone may be communicating by Bluetooth in any way when I specifically have BT and BT discovery disabled. Can you get me a citation on that, especially for Android?

Thanks,

Dougal

[Anton Kapela]

On Fri, Sep 14, 2012 at 1:25 PM, Dougal <zelef...@gmail.com> wrote:
> I am bothered by your statement that my phone may be communicating by
> Bluetooth in any way when I specifically have BT and BT discovery disabled.
> Can you get me a citation on that, especially for Android?

start here: http://www.palowireless.com/infotooth/tutorial/baseband.asp

normal state of a phone (usually the 'phone' is the master in a BT
piconet) is standby. which means it's not txing anything.

if you've ever paired devices, the master will (generally) be sitting
in 'park' state, which is only slightly more power suckage than
standby. this is to periodically synchronize the piconet hoping
sequences (which each of the slaves attempts to track) in the case the
user wishes to quickly acces the piconet (i.e. make a call on a bt
headset, send some packet data, etc).

so, it's question of the stack -- if you ever paired something, and
the device is not near your phone, the phone stack has to decide: stay
in deep idle state, stay in park state, or some mix of the two states
possibly.

I cannot predict how uninformed a given software dev might be, but
given what i've seen of droid, I'd assume the highest level of naiveté
at all times.

-tk

[r...@kregerville.com]

Does anyone have an Ubertooth one? I am sure we could learn a lot more
about how they capture the data and what type of data they are
capturing. http://hakshop.myshopify.com/products/ubertooth-one



Rob

[Joe Kerman]

thats what i was thinking... BT xmit is disabled by default! so the
sample would be "people who have enabled bluetooth on their phones at
least once"

it seems horrible for traffic management, because im quite positive
theres more people traveling to EPIC who have bluetooth on, than
traveling to <place where people dont get paid much>

[Claus Moberg]

Does Madison even have traffic?
<sent from San Francisco traffic jam>

Sent from my iPhone

[Anton Kapela]

On Fri, Sep 14, 2012 at 2:27 PM, Claus Moberg <chris....@gmail.com> wrote:
> Does Madison even have traffic?

+1 (having lived in chicago/nyc/socal/miami)

-tk

[Joe Kerman]

Having recently lived on the beltline @ Todd for 6 weeks, more than I
ever realized.

Downtown? It's not so bad, even on gamedays. But if there's any
sort of accident whatsoever between park and gammon, it's a parking
lot

[Rob Kreger]

I think this is the company that makes the boxes we are seeing on the
highways. Some of the cut sheet information is rather interesting. there
are a few pictures of what is in the box as well. From the video on the
benefits tab it looks like they are looking that the MAC address.
http://www.trafficcast.com/products/view/blue-toad/


Rob

[Brendan O'Connor]

That's what I would do, certainly.

---BFO

[Dithermaster]

I see no benefit and only loss of useful information in disrupting this system. Wouldn't having undisrupted information help us all more?

I don't know why they have to do this themselves. Google already has this information. Many device using Google Maps anonymously upload when in transit to contribute to the traffic information database. You'd think they'd make that available to municipalities.

///d@

[Dougal]

I don't like this because I am not okay with having my daily movement tracked by the government without my knowledge or consent.

[Scott Fradkin]

Ah. Now I know what those are. They're all over the city.

Scott

---

[Anton Kapela]

But they do -- someone has to ask. 

And yes, passive collection from iPhone and droid, brilliant. Also, good data. 

-Tk

[William LaFrance]

The hidden bonus is that your taxes paid it.

Isn't this equivalent to wiretapping? I'm sure they can decode Bluetooth hands free conversations.

Sent from my iPhone

[Anton Kapela]

That part is ciphered up, but who knows how well initialized...

Most folks pair with "0000" ...so yea

-Tk

[Dithermaster]

But yet you fully expect them to provide nice roads for your use, and perhaps complain if there is congestion?

///d@

On Sep 14, 2012, at 7:01 PM, Dougal <zelef...@gmail.com> wrote:

[William LaFrance]

s/provide/take a large sum of my money and overpay contractors to stand around and do nothing/gi

Not sure about Dougal, but, yes.

Where are these "nice" roads being spoken of?

Sent from my iPhone

[Claus Moberg]

Where are these "nice" roads being spoken of?

Door county.

Sent from my iPhone

[Nick Terrible]

All,

The ones that are empty.  :P

The problem is a little bit of everything; also known as the drivers. 

This is a really cool book.

http://www.amazon.com/Traffic-Drive-What-Says-About/dp/0307277194/ref=sr_1_8?ie=UTF8&qid=1348331165&sr=8-8&keywords=traffic

-- Nick

Thanks,

Nick Terrible
nick.t...@gmail.com