slewis

Another way to make a signal go further is to transmit at a lower data rate (thus spreading your signal out over time so that in effect you have more power in the signal). The FCC limits "dwell time" in a single channel to .4s in the 900MHz band.

Yet another way to increase range is to increase your receive sensitivity. Lora's Chirp Spread Spectrum coding actually allows signals to be received below the noise floor. You can liken this to decrypting data: to an observer the signal looks like noise, but if you know how to look within the noise you can pull the actual coded information out.

All of these LPWAN technologies use different forms of coding and signal spreading over time to get long range. Note how spreading your signal over time means your throughput goes down.

Would love to hear thoughts on it. Email address in my profile.

Other technologies can have many more simultaneously communicating devices. In the case of OnRamp/Ingenu, a factor of 1600 more due to their encoding scheme.

Narrowband technologies like SigFox (based on TI radios), have way more than 64 channels available in the US, I believe in the range of 1000, but are more susceptible to interference.

The counterpoint to mesh is that it's a) much more complex to implement b) uses more power since nodes need to relay each others' communications.

It will be interesting to see how it plays out, and who ends up crying in whose martinis as you say.

It's unfortunate because there is actually a lot of beauty to be found in literature, and each reader is free to find his or her own.

Beyond beauty literature helps establish empathy by exposing you to the inner-thoughts of different types of people, and it inspires creativity, both of which are useful in any field.

And 5k is too low. Google gave a 10% raise across the board around the time this information came out. So assume 150k salary * 10% = 15k. Salaries also continued to rise more rapidly after the 10% raise, but it's hard to say by how much without having access to the internal data.

Or to put another way, a smart person who wants to effect change should try to develop a sense understanding of those they want to effect, it's harder to be mean to people whose "shoes you've walked in".

The hardware design isn't open-source, but all the software is, and it's available now for 19euro per module.

It's built on Atheros' AR9331 chipset which means you get to use the awesome open-source ath9k driver.

But there is no one true code to test ratio. If you're trying to become a better programmer be wary of dogma.

As posted here the other day, airbnb didn't have much testing until a year ago: http://nerds.airbnb.com/testing-at-airbnb/

I'm not saying either way is right or wrong, which is kind of my point.

For example, for Pebble you said, "put this joke in there: 'I bet you guys really want to check your phones right now but you can't because it would be rude... if you had one of these babies on your wrist you'd be able to see those precious emails'".

OK maybe not the most world-changing example but there were 100 more of those.

I'm sure Sam will be excellent at this too.

For those who haven't witnessed this: pg stands there for an entire day (maybe longer now), watching every pitch, slicing and dicing like a samurai. It's super rapid-fire, and with one or two pieces of advice each presentation doubles in effectiveness.

If you want complete control, while leaving the hosting up to a team that rocks and knows how to do it (they handled AdBlock's campaign for example, tons of traffic) CrowdtiltOpen is the way to go.

Syncing is an interesting problem for sure. It's really a question of how precisely you can sync the clocks between devices. Our current method is fairly naive, we let ntp sync clocks for us, count the number of samples played, and drop samples every now and then on devices that are behind. This gets us to 2ms accuracy between devices. We could get much lower with a better algorithm. But 2ms is very difficult to notice in a home listening situation between rooms.

We are also looking at supporting DLNA or some other local music protocol due to interest we're seeing.

Btw, love Squeezebox, Dean Blacketter, one of the founders and CTO is a friend and advisor to us.

Please, everyone, if you witness this type of rude behavior, speak up. We are all, male, female, undecided, both etc. responsible for improving treatment of non-males in tech. Take an active role.

I love how people missing the point actually reinforces the point. Well done.

Agreed, the Android emulator sucks and I don't use it. One of its many flaws is that it doesn't support multicast, which is pretty much a requirement for doing device discovery in a remote control app.

Android's OS integration also makes for better demos of our app. Since it's a remote control for another device it makes a lot of sense to have lock-screen and pull-down controls. We can't show that off on iOS.

Finally, the Android developers that I know simply don't use the simulator, they always use hardware. I found it strange coming from iOS, but I've gotten used to it. I weight this negative much lower than the deployment advantages that Android has for prototyping.

Of course in the end you'll have apps on both platforms, but here's a vote for doing early development on Android.