pharkmillups

We recently converted an internal dashboard for the Helium blockchain to a public tool and the reception/usefulness has been awesome. (For anyone interested -> http://dashboard.helium.com)

Congrats to the team. Well-deserved.

For anyone interested in more reading:

- The whitepaper that goes into more detail on this can be found here: http://whitepaper.helium.com

- A lot of the code that makes this possible is pinned to the Helium repo on GH: https://github.com/helium/

Mark from Helium here. Fair point on not publishing designs. You're not the first to bring this up and we have plans to make this a non-issue in the future. Shoot me a note - mark@helium.com - if you're up for talking further. Any other thoughts / critiques would be most-appreciated.

If you're looking for a sensor platform that will let you quickly deploy a sensor that will run for a few years on a pair of AAs, check out what we're putting together at Helium [1]. We just rolled out the presale of our Helium Atom Development Board [2] which uses the Atom - our drop in connectivity and compute module - as the basis for a sensor development board that is actually fit for production. The OS that runs on the module - cleverly named Helium OS [3] - is the basis for our edge programmability and abstracts the annoying, hard things like battery/power management, wireless, and security. Also OTA upgrades are built in. :)

mark@helium.com

[1] helium.com [2] https://store.helium.com/ [3] https://www.helium.com/helium-os/

Very cool. I had heard rumors that Tim was working on this. He did some great work with the NoSQL Tapes [0] a while back. I'm hoping these are of a similar caliber.

[0] http://nosqltapes.com/

Very cool. What's the thinking behind shipping with Swift support despite it still being in beta?

Cryo, we know that module well and it works with Helium. Dresden make an excellent SoC. Shoot us an email, hello@helium.co

Hey Sanddancer, Helium can run without direct access to the internet. It's designed to be a small portable stack. Shoot us a message. Would love to hear about some of your use cases. hello@helium.co

-sean

Hey Madaxe. Helium never has to know the contents of a payload. We encrypt it to keep the information secure, but you can further encrypt that payload via your own requirements with very little effort.

Hey noonespecial, Just a quick point. The radio is based on 802.15.4 which is an open standard. Much of our end node code is going to be open source, if not all.

Shuank, helium edge routers will have a global footprint to minimize latency to the internet. We always want latency from the internet to helium enabled devices to be as low as possible.

Hey Kator, We figured it out. Hope you can give it a shot now.

jrockway, would love for you to test with us.

dr, Can send you data sheet on module. Email hello@helium.co - Not sure on 1v8 - SPI / UART - All module and bridge programming happens OTA - We have arduinos for making pocs, the module is currently 19x12mm I believe. - Our next module will have u.fl. (in the works now) - Network goes in both directions. Access from the internet via ipv6. drFritz.xx.helium.io. -You can also communicate to other devices. The other device can be anywhere as long as it's on the helium network and you are allowed to speak to it.

shoot us an email, would love to speak more!

Kator. we are looking into it. Please feel free to email hello@helium.co

Chris very cool. We have a golang driver for helium that will be opened up soon.

The bridges use multiple omnidirectional chip antenna per radio. Each radio also has a u.fl connector so you have choices. Hope to see you sign up for the beta. Would love to see this in action.

stevenrace: Custom non Zigbee firmware. Let's talk hardware design over email some time? sean@helium.co

Hey Speeq -

Negative. We are completely different products.

Hey Amscanne -

There are two things we're trying to convey here (but rest-assured we're not trying to be misleading):

1. We can support a lot of connections. I mean a lot. This is based on our design, but truly limited by the receiving radio.

2. 50 square miles is optimal conditions. It's hard to quantify how bridges and radio enabled devices will work in populated metropolitan areas. These numbers are solely based on field testing, not in metro areas.

Hey Sweis -

There's a whole process to how the secret for each device is created. That secret is used to ensure helium connectivity is safe. You can then securely implant your own secret into a chip we use and that secret can be used to encrypt your payload. Helium never has to know what you are sending. We just need to know where it's going so we can get it there for you.

We'll be posting more docs on this in the coming weeks and months. Feel free to shoot me an email if you want to chat more before they are available.

You should probably work here. -> mark@helium.co

Hey Kazinator -

We only use the same hardware standard as Zigbee. Nothing else.

Hey amscanne -

It's solely based on throughput. The helium bridge has very little state. Our true limitation will be how much we can put in the air to a single bridge. Our metro networks will have a lot of bridges.

We're streaming talks live today and tomorrow from RICON West in San Francisco.

ricon.io/live.html

There are no less than six talks dedicated to this release.

A bit off-topic, but if you've got a moment I would love to pick your brain a bit more about your Riak usage. Shoot me an email if you're up for it - mark@basho.com

We're working on expanding the official counters docs. We'll also have a blog post up about it next week.

Basho Hacker Sam Elliott started a CRDT cookbook that will walk you through using the counters in 1.4 (and eventually the new data types we add). That should get you started.

https://github.com/lenary/riak_crdt_cookbook/tree/counter_ex...

Enjoy. Also, come to ricon.io/west.html. We'll be talking plenty about Counters and all the huge stuff coming to Riak in the near future...

Mildly-shameless plug here: Riak CS will a big topic at RICON EAST this May in New York City (in addition to Riak and other distributed systems goodness). You should all attend.

- Conf info: ricon.io/east.html - Tickets: http://ricon-east-2013.eventbrite.com/

If you haven't done so already, I would highly-recommend taking a look at Basho Bench, our open source benchmarking tool for Riak.

http://wiki.basho.com/Benchmarking.html https://github.com/basho/basho_bench

Yes. Docs are high on our list of things to revamp. We should be refacing and improving in all areas starting right about now...

Somewhat of a shameless plug here: Basho is having conference in October called RICON. It's in San Francisco, and it's two days dedicated to Riak, developers, and distributed systems in production. And there will be plenty of chatter about Riak 1.2 (and 1.3).

http://basho.com/community/ricon2012/