4 ms·

Wow, this is incredibly well-executed. I worked in a lab with Bunnie years ago; it's great to see he's still as thoughtful and thorough as he was then. I wish I

by pcl 11y ago

Wow, this is incredibly well-executed. I worked in a lab with Bunnie years ago; it's great to see he's still as thoughtful and thorough as he was then. I wish I had the dedication, time and aptitude to execute as well as he does. A great tidbit: I designed a very simple protocol which will only reveal if your friends are nearby, and nothing else. Every badge emits a broadcast ping every couple of seconds. Ideally, I’d use an RSSI (receive signal strength indicator) to figure out how far the ping is, but due to a quirk of the radio hardware I was unable to get a reliable RSSI reading. Instead, every badge would listen for the pings, and decrement the ping count at a slightly slower average rate than the ping broadcast. Thus, badges solidly within radio range would run up a ping count, and as people got farther and farther away, the ping count would decrease.

tlrobinson 11y ago
I didn't really understand this part: decrement the ping count at a slightly slower average rate than the ping broadcast Is he saying he's reducing the power of each subsequent transmitted ping, causing nearby units to see more pings than far away units, or something else entirely?
- codyb 11y ago
  I found it confusing too so I checked out the linked code [0]. Looks like when you're actively receiving pings from friends it slows down how fast that friends ping counter on your badge decreases so they accumulate a larger ping count and appear "stronger" or closer to you. Then as you stop receiving pings (I assume, I'm at work, didn't delve too deep), the ping decrement rate goes back to normal and they get "weaker" or farther from you. Absolutely a super neat way to solve the issue of not being able to account for signal strength. [0] - https://github.com/bunnie/chibios-orchard/blob/orchard-r2/orchard/orchard-app.c#L195 https://github.com/bunnie/chibios-orchard/blob/orchard-r2/or...
  - triplesec 11y ago
    In practice, you'd have some friends on your list even when you were down a couple of blocks (at C for the portas, for exmaple) and couldn't actually get through, or it was definitely at the edge of range and you might just have got a signal through if lucky (I tried down there and never did), so there is some lag involved, but some intelligence helps you figure that out.
- daxelrod 11y ago
  Here's what I think is happening (without actually looking at the code). 1. For each person, store an integer ("ping count"). 2. Whenever you receive a ping from that person, increment the ping count. 3. Periodically decrement the ping count, stopping at zero. 4. When a person's ping count is zero, do not display them on the screen. Let's say a ping is transmitted every second. "decrement the ping count at a slightly slower average rate than the ping broadcast" means that #3 should happen every 1.2 seconds. The result of this is that, if somebody is solidly within broadcast range, their ping count constantly goes up. If they are just past the edge of broadcast range, they'll start getting signal loss. The result is that some of their signals will be delivered and some won't. This will mean that their ping count will slowly drop. If someone is completely outside of broadcast range, their ping count will drop more quickly.
  - jchrisa 11y ago
    This is similar to how direct stream digital audio (SACD) encodes with a 1 bit dac at 2.8 MHz bitrate. https://en.wikipedia.org/wiki/Direct_Stream_Digital https://en.wikipedia.org/wiki/Direct_Stream_Digital Cool tidbit: you can do the digital to analog for this with a low-pass filter.
hobolord 11y ago
reminds me of avalanche tracker beacons

by pcl 11y ago

tlrobinson 11y ago

I didn't really understand this part: decrement the ping count at a slightly slower average rate than the ping broadcast Is he saying he's reducing the power of each subsequent transmitted ping, causing nearby units to see more pings than far away units, or something else entirely?

codyb 11y ago
I found it confusing too so I checked out the linked code [0]. Looks like when you're actively receiving pings from friends it slows down how fast that friends ping counter on your badge decreases so they accumulate a larger ping count and appear "stronger" or closer to you. Then as you stop receiving pings (I assume, I'm at work, didn't delve too deep), the ping decrement rate goes back to normal and they get "weaker" or farther from you. Absolutely a super neat way to solve the issue of not being able to account for signal strength. [0] - https://github.com/bunnie/chibios-orchard/blob/orchard-r2/orchard/orchard-app.c#L195 https://github.com/bunnie/chibios-orchard/blob/orchard-r2/or...
- triplesec 11y ago
  In practice, you'd have some friends on your list even when you were down a couple of blocks (at C for the portas, for exmaple) and couldn't actually get through, or it was definitely at the edge of range and you might just have got a signal through if lucky (I tried down there and never did), so there is some lag involved, but some intelligence helps you figure that out.
daxelrod 11y ago
Here's what I think is happening (without actually looking at the code). 1. For each person, store an integer ("ping count"). 2. Whenever you receive a ping from that person, increment the ping count. 3. Periodically decrement the ping count, stopping at zero. 4. When a person's ping count is zero, do not display them on the screen. Let's say a ping is transmitted every second. "decrement the ping count at a slightly slower average rate than the ping broadcast" means that #3 should happen every 1.2 seconds. The result of this is that, if somebody is solidly within broadcast range, their ping count constantly goes up. If they are just past the edge of broadcast range, they'll start getting signal loss. The result is that some of their signals will be delivered and some won't. This will mean that their ping count will slowly drop. If someone is completely outside of broadcast range, their ping count will drop more quickly.
- jchrisa 11y ago
  This is similar to how direct stream digital audio (SACD) encodes with a 1 bit dac at 2.8 MHz bitrate. https://en.wikipedia.org/wiki/Direct_Stream_Digital https://en.wikipedia.org/wiki/Direct_Stream_Digital Cool tidbit: you can do the digital to analog for this with a low-pass filter.

hobolord 11y ago

reminds me of avalanche tracker beacons