Hacker News Reader

Comment by chrissnell | Hacker News Reader

Lots of misinformation in these comments. For those dreaming of building a mesh Internet alternative, consider that these devices are not being designed for TCP/IP. From the looks of the KS page, they are going to speak a mesh protocol but likely something proprietary, perhaps similar to ZigBee, that is designed as a wire-replacement protocol for Arduino-to-Arduino comms. That's a long way from Internet routing.

They are offering a WiFi shield but it's backed by the Arduino. Not really something that you want to mesh-route TCP/IP, in my opinion. There are more suitable choices.

I'm also a little concerned about selling a device that is so high-powered by default. I'm assuming that they're using 900 MHz here. Is it really necessary for everybody to transmit with enough power to reach 1 km? In the US, there's a FCC rule that says that amateur radio operators use the minimum power necessary when transmitting. I'm not sure if it applies to a device like the Flutter but it probably should.

View on HN

From the datasheet of the TI radio they're using[0], the maximum programmable output power is +12 dBm, which is about 16 milliwatts.

There's no way you're going to see the advertised range with the antenna pictured. For comparison, the wifi hardware in your laptop typically outputs around 100-200 milliwatts.

Edit: TI appears to have a "range extender" part (i.e. a power amp) that can kick the output power up to +27 dBm (500 mW) at the band that they're using. I don't see any mention of this part on the kickstarter page, but this is the only plausible way I can see for them to get anywhere near the range advertised.

Half a watt seems pretty high to me too, but apparently it's comfortably within FCC limits [1][2], and since ISM devices are designed for consumer use (as opposed to licensed use by a competent radio operator), I don't think the same rules about being clever with output power would still apply here.

[0]: http://www.ti.com/lit/ds/symlink/cc1101.pdf

[1]: http://www.afar.net/tutorials/fcc-rules/

[2]: http://www.beagle-ears.com/lars/engineer/wireless/fccrules.h...

Hah, thanks for the edit. Yeah we've already gotten the range. I've even checked the output of our boards with a radio expert (google Earl McCune, he's an advisor), and using his many expensive Agilent scopes we've experimentally verified that performance of my design is pretty much exactly on par with the reference designs, taking into account that we are using a custom designed RF balun [1] instead of the discretes they use on the reference design. Our RF Expert confirmed I had made a good choice with that, as the losses are tiny compared to ease of manufacturing it provides.

[1] (I think it's this one, I'd have to check the part number, they have a couple similar ones). http://www.johansontechnology.com/datasheets/chipset-specifi...

Are you sure you're able to legally transmit at 1km. Had thought antenna gain + transmit power had to be around 0 dBm, at least for 434MHz.

Hadn't seen the rules for 900MHz though.

First thing that crossed my mind too. It's definitely forbidden in Europe.

Yup, but we can 868MHz in Europe, and with all the support from international backers I think we may end up doing that as a stretch goal! Just have to talk it our with our RF expert, which we're doing!

The Xbee Pro 900 is 50mW, for reference.

This is what I initially thought as well, having built an ISM band transceiver around the 350/400 MHz bands a few years ago. I recalled much lower power limits.

(I had posted something along the lines of "there's no way in hell the FCC would let you transmit at half a watt" but have since edited).

Apparently the 900 MHz bands are different, and the FCC has rules governing output power going into the antenna (1 watt), as well as an effective radiated power (which essentially places limits on your antenna gain) (4 watts).

[1]: http://www.afar.net/tutorials/fcc-rules/

Wow that is very much radiated power!

I remember range testing a 434MHz product and being hundreds of meters away (line-of-site). The product passed FCC testing.

So a watt going into a 6dBi antenna... Flutter's measurements make sense now!

I'm pretty sure that to get 1 Watt you have to use direct sequence or frequency-hopping spread spectrum under FCC part 15.247... Just sitting on a frequency as a 15.249 device or general ISM device you aren't allowed to use much power at all.

See FCC part 15.247: http://www.gpo.gov/fdsys/pkg/CFR-2001-title47-vol1/pdf/CFR-2...

I work with UHF Gen2 RFID readers all day which do 1 Watt/30 dBm into 6 dBi = 4 Watts EIRP, but they are definitely required to do hopping.

EDIT: and after looking at the 50 mW 900 MHz XBee units, they are doing hopping as well according to their datasheet.

So it looks like if you want to keep the range, you may want to start looking at hopping algorithms...

From my reading of the rules, you are limited to broadcasting +36 dBm EIRP (30 dBm [1W] into a 6 dBi antenna -> 4W EIRP). This can be a single frequency. In the 900 MHz band, your bandwidth is limited to 902-928 MHz (US limitations, different in other global regions).

You can happily beam out a 915 MHz single-tone CW carrier at +36dBm EIRP all day and that is fine.

The reason your gen2 reader is frequency hopping is not FCC mandated but protocol mandated. The UHF RFID gen2 tags have a high manufacturing variation and the RF frequency response varies greatly between tags. Some tags may be resonant closer to 902 MHz and some tags may be resonant closer to 928 MHz. Hopping over various frequencies allows the reader to address all tags in its view.

The only reason the readers are "required" to do hopping is to conform to the gen 2 protocol. In fact, from what I remember you can use the LLRP (low-level reader protocol) to stuff the frequency hopping table with a single frequency so that it will stop frequency hopping.

(My PhD was on high-data rate (up to 100 Mbps) rfid/backscatter communication.)

Wifi operates at a higher frequency and data rate, which both reduce range.

exactly this ^

Sigh

I was wondering whether I'd get called out for omitting this. You're right, of course. :-)

Well, you're partially right (and it's a bit of a mess, which is why I left it out in the first place). Yes, increasing the data rate reduces range when all else is equal. The carrier frequency doesn't actually matter. The bandwidth does matter, but not in the way that you'd expect. Increasing your channel bandwidth actually increases your range when your receiver is noise limited (which is necessarily the case when you're making the range/bitrate trade-off). But the "power" term in the standard formulas assumes you're measuring the total power in your band (not carrier power). So you can't reap the benefit of doubling your bandwidth without also doubling your transmit power (unless you're using a true spread spectrum transceiver, which is a different beast).

There are plenty of other factors, but when you're thinking about these things, you ultimately want to form an intuition for "what is the minimum energy per bit needed to make my receiver happy?" and "how much transmit power do I need to deliver that energy, given a specific antenna and desired range?" [1]. This analysis lets you ignore the specifics (modulation technique, multiple carriers, multiple antennas, spread spectrum, etc) that make it difficult to compare this TI radio and your 802.11n card, but still gives you a very accurate result.

My original point (which still stands) is that you can't feasibly build a 1 kbps transceiver with 16 mW transmit power and a two inch monopole antenna and expect to get anywhere near half a km of range with the TI radio. It simply isn't sensitive enough.

[1] http://en.wikipedia.org/wiki/Eb/N0

(As an aside, Eb/N0 was one of those things that I found incredibly confusing when I first learned about it in a communication theory class - I recall several homework assignments where we had to solve for Eb/N0 symbolically for various theoretical transceivers. I only realized how useful it was after building real radios and plugging in actual numbers. Once you get the hang of it, it becomes a very good bullshit detector for "overly optimistic" range, bitrate, and power trade-offs that doesn't require spending hours in front of a simulator.)

It doesn't sound like you're familiar with the Friis equation [1], which shows how carrier frequency is inversely related to transmission distance.

The receivers are probably around -90 dBm sensitivity, which would place the system's range around a kilometer and would improve depending on their PA and LNA characteristics.

[1] http://en.m.wikipedia.org/wiki/Friis_transmission_equation

Please. This is actually a common misconception about the Friis equation. It assumes an isotropic antenna with an effective area that is dependent on lambda. But physical antennas have an effective area that varies with lambda squared (obvious on something like a horn or a dish with a real 2-D aperture, but even simpler antennas behave this way). It turns out that this perfectly cancels out the frequency dependent term in the equation when the transmitter and receiver use the same antenna, leaving you with only the reduction in power density as you move away from the transmitter.

I had a professor give an epic lecture about this several years ago, but this is the best I could find on short notice [1].

As it turns out, there is a real source of frequency dependence in your path loss, which is the atmosphere. Your link budget calculation is really just an annoying geometry problem. Conservation of energy still holds, so you should be immediately suspicious when the naively applied Friis equation (which does not take atmospheric effects into account) makes received energy vanish just because you cranked up the frequency. Just as you should be suspicious when you receive more energy than you transmit when you're in the antenna's near field. Always know what your approximations imply.

The receivers are actually a bit more sensitive than that (the TI chip is ~-120 dBm at the target frequency; the whole package could be close to -114 dBm if designed well).

The claim I made was that you can't get half a km on 16 milliwatts. I cited 16 milliwatts because it's the max transmit power of the TI chip alone. You cannot make this go half a km with the antennas shown on the kickstarter page. You'd either need more power, or one of the antennas would need to be a dish. Even in an unreasonably quiet environment, you'd run out of energy at the receiver way before running into frequency or bitrate dependent effects.

But it turns out that 16 milliwatts is not the output power used. TI makes an amplifier that increases the output power to half a watt. In this case you'll easily get the half-km range.

[1]: http://www.dslreports.com/forum/r24210307-Reconciling-the-Fr...

You're right we're speaking a bit tangentially. Hadn't heard of the Friis argument that frequency doesn't matter as long as antennas on RX and TX are the same. I'm not sure I understand it yet.

Nevertheless, let's get some numbers on the page to see if I'm misunderstanding the subject.

Here's a rough link budget with some estimates

TX/RX antenna gain is around 0dBi (seems reasonable [1]) TX power = 16mW = 12dBm [2] RX sensitivity = -90dBm (personally, better than -100dBm seems aggressive)

Roughly, our link budget formula can be... Path loss = TX power + TX gain + RX gain - Rx power [3] Path loss = 102dB

Ideal free space loss over 1km at 900MHz is around 91dB [4]. Therefore, we have about 10dB margin in our link budget to transmit 1km. We also have a few dB margin in the antenna and receive sensitivity estimate.

[1] http://store.rfdesign.com.au/antenna-900mhz-2dbi-monopole-rp... [2] http://www.cpcstech.com/dbm-to-watt-conversion-information.h... [3] http://skypilot.trilliantinc.com/pdf/link_budget.pdf [4] http://en.wikipedia.org/wiki/Path_loss

They cancel perfectly when the antennas are the same. There's a scale factor when they're different, but the frequency dependence still goes away.

So I'm adding about 10dB for noise, and getting a path loss that's about 15 dB higher, giving me an expected range closer to 100 m. What are you using for the antenna's effective area?

Do you agree with lpmay's explanation of Friis? Path loss increases as frequency increases. However, if aperture is constant while frequency decreases, which increases path loss, gain increases, which offsets the increase in path loss, and there is no change in link budget.

My receive sensitivity has noise included. It's why I think -100dBm seems for a 900MHz TI chip (could be wrong? didn't design this system...). Factor in noise/packet loss/PER or however you want to quantify, and I'd guess you'll get to a measured RX sensitivity of ~-90dBm.

Mentally, I equated RX sensitivity at data rate with RX power, which shouldn't be done for explanation purposes, but my original formula should still hold.

What are you using for path loss [1]?

[1]: http://en.wikipedia.org/wiki/Path_loss

Take this as the kind of half-cooked thought it is at this point (long day, about to go to bed and don't want to crack open the textbook), but the fact that your path loss leaves 10dBm of power above your Rx sensitivity doesn't mean you have 10dBm of link margin. I'm not completely sure, but I'd guess it means you have 10dB of SNR (theres a units from dBm to dB thing I haven't completely resolved in my head). Whether that makes your link work or not depends on the bitrate, modulation you choose and BER you can accept (and etc). If your modulation scheme needs 9dB of SNR (proportional to Eb/N0) to operate at an acceptable BER, your system may only have 1dB of actual link margin.

We're circling around some good stuff. Night though, thanks for the information to think about.

Can you explain more what you mean? I think you're getting at something I agree with, but you're also saying some things I don't think are quite right...

Firstly I don't know what you mean by the Friis equation "assumes an isotropic antenna". It explicitly accounts for the gain of each antenna, in the direction of the link, relative to an isotropic radiator. The fact that it's relative to an isotropic radiator is just how all gains are measured. In fact, the antenna pattern doesn't matter at all to the link, only the gain in the direction of the link (Friis assumes no multipath). Whether the receive and transmit antenna are "the same" or "different" really doesn't make a difference.

This is the distinction I think you're trying to make, and which I agree with:

If gain is held constant, link margin improves as frequency decreases because of reduced path loss at lower frequencies. If instead antenna aperture is held constant as frequency is lowered, antenna gain will decrease at the same rate as path loss improves and there is no net effect to the link.

Both answers are technically correct, in a fixed gain scenario where your antenna can grow as large as necessary to hold gain constant, (or the scenario doesn't allow for high gain, narrow beamwidth antennas) lower frequencies will make longer links. In systems where aperture is constant (which is the case for many practical systems) antenna gain will improve as quickly as path loss degrades when you go to higher frequencies, and there is no net advantage at any frequency.

Sure, sorry.

So you're right that the two antennas being the same doesn't really matter. What I meant was that if the two antennas are the same, the entire part of the Friis equation that deals with frequency dependence goes away (the lambda / (4piR) part). If the antennas are different, the frequency dependence still goes away, but there's some new scale factor.

There are two interesting things that you want to know about your antenna. The gain, which measures directivity, and the effective area, which roughly corresponds to the cross section of sky that the antenna can listen to. Going from the transmitter to the receiver, you have some transmit power going into the antenna. You now want to figure out what the power density is in the vicinity of the receiver. You get this by spreading the power over a sphere and multiplying by the antenna gain of the transmitter.

Now you need to know how much of that power density is seen by the receiver. This is slightly more complicated than the transmit case, because you now have to take into account the antenna gain of the receiver (i.e. where it's pointing), which the Friis equation considers, as well as how big a chunk of sky it's listening to (i.e. effective area), which the Friis equation does not consider.

It turns out that the effective area is a function of lambda^2 (an antenna of some size and ideal frequency will have an easier time collecting higher frequency signals, and a harder time collecting lower frequency signals). So the lambda^2 from the effective area cancels the 1/(lambda^2) from the Friis equation.

"you can't feasibly build a 1 kbps transceiver with 16 mW transmit power and a two inch monopole antenna and expect to get anywhere near half a km of range with the TI radio"

I mean... you say that, but we did, and we're not doing anything special, I just set two android phones to volley their GPS position over USB to the board, send it over radio, and calculate the distance on the other end. I then verified the calculations manually using google earth and landmarks.

Here's what texas instruments has to say [1] about the radio: "You can achieve a range of several km with the CC1101 without any problems (line of sight). The output power can be programmed up to 12dBm and the sensitivity level on the receiver is dependent on the programmed baud rate. With a sensitivity of -112dBm and an output power of 12dBm, 915MHz ; the expected range with Friis equation adapted to take into account the height from the ground would be approx 3km."

We're being advised by Earl McCune, a serious Silicon Valley Radio expert (google him, he's awesome), and he donated some of his time to help test the board with his nice Agilent RF stuff. He was impressed with the performance of this little chip, and was also impressed that my layout nearly perfectly matches the TI reference design.

[1] http://e2e.ti.com/support/low_power_rf/f/155/t/15984.aspx

Wait, so you're not using the additional TI power amp?

Well shit... Now you have my attention. I obviously missed something if I was off by two orders of magnitude. I'll take a closer look when I have some more time.

In the meantime, I would strongly suggest adding as many technical details to the kickstarter page as you can (output power, for starters. A (rough) schematic would be fantastic).

Edit: Actually, do you have any specs on the antennas you've tested?

Back of the envelope, and assuming their design is the same like their board pictures posted on the kickstarter page (i.e. no PA, all RF done inside the chip):

The CC1200 puts out 14 dBm [1]. Receive Sensitivity from the datasheet at 915 MHz is -122 dBm @ 1200 baud, -110 dBm @ 50 kbps, and -97 dBm @ 500 kbps. Very good overall. (all these values are from the datasheet.)

Free space ideal path loss at 915 MHz and 1 km is -91.7 dB [2]. This gives an ideal budget of 44 dB. Toss in some antenna gain and you should have plenty to play around with for losses in the passives, connectors, antenna alignment, etc. 3 km is pushing it, with another 10 dB of path loss. So I would think 1 kilometer is easily attainable at 1200 baud with this chip.

However, things start to change with FCC compliance... 15.249 devices (a lot less limitations, including fixed frequency) can transmit at max -1 dBm. [3] So the compliant device at 50 kbps, -1 dBm, 1 km has 15 dB ideal budget, right on the edge of working. 500 kbps is probably not going to happen at 1 km except in perfect conditions.

So now you want to use hopping as a 15.247 device to get the limit up to 30 dBm/1 Watt. This chip doesn't support DSSS, so we are frequency hopping. This limits us to a channel bandwidth of 500 kHz, so you can't run at high speeds - maybe 200 kbps or so? Downside is you are spending some time hopping and waiting for PLLs to stabilize, there is a chance for interference on certain frequencies resulting in periodic dropouts until you hop to the next frequency, and the software side/hopping coordination is tons more complex. But you would be able to communicate pretty far!

Also, note that RF is very unfriendly and link budgets can easily be used up with obstacles in the way, walls, trees, not to mention pesky humans etc.

Hopefully this clarifies some things? Please let me know as well if I am off anywhere, I know a little about this but it is also late...

[1] http://www.ti.com/product/cc1200 (see datasheet) [2] http://www.qsl.net/pa2ohh/jsffield.htm [3] http://rfcalculator.mobi/convert-dbuv-3m.html, 15.249 allows 50 mV/m @ 3m = 93.89 dbuV/m @ 3m = -1.34 dBm EIRP. [4] FCC 15.247 & 15.249

I can't speak for the creators of Flutter, but I can definitely attest to that TCP/IP with full mesh routing should be doable with the Flutter hardware. We (Thingsquare) have the CC1101 as one of our supported hardware platforms and use it to run full TCP/IPv6 networking over a self-forming mesh. The system is used in a number of commercial products and systems. The chip-level firmware is open source so I guess the creators or backers of the Flutter system might even be able use it pretty much out of the box: http://thingsquare.com/tech/

One of the things needed to get full IP routing working is to do channel switching over the sub-GHz connection. Both the FCC and ETSI regulations let you transmit at a higher power and with longer bursts if you switch channels with a regular interval and if you back off if you find other transmissions in your channel.

That said, TCP/IP routing over a sub-GHz CC1101 link isn't going to be very fast. It is suitable for automated devices but not a general purpose replacement for WiFi connectivity. For IEEE 802.15.4g-compliance, the raw bit rate is 50 kbit/s which isn't a lot. The CC1101 can be run in faster, non-802.15.4g compliant, modes though.

Agreed. This isn't going to form the 'alternate Internet' that some people are clamoring for. But there are tons of applications (machine->machine) where a basic serial/ssh is all that's required.

We've had similar hardware in the field for 3+ years now, covering ~50 square kilometers in a mesh configuration.

Absolutely! There's lots of hardware around, but being able to turn an Arduino project into an emergency beacon or IP link has some benefits too, and $20 is likely cheaper than what's been around. At $20 these are commodity prices, which I don't think we've had for high quality general purpose computing + wireless platforms.

It's always good to see cheaper hardware - our early 'proof of concept' hardware were based on an 'Arduino FIO' + 'XBee Pro' which came out to ~$60. Then quickly migrated to a TI MSP430 + CC2500(CC1100) which slashed the price to <$20 all told. We're now on the ARM M3/M4 SoC bandwagon as well. So I understand that angle.

I'm sorta curious as to what you plan on using the $80k for. Are you going to farm out PCB fabrication to OSHpark/China/whatever - or get a pick and place machine, CNC mill, and try to do everything inhouse?

Anyways, best of luck with the project.

We have a lot of resources for manufacturing in China. I've personally ordered a few thousand assembled boards from Gold Phoenix through the course of my old job, which was... fun.

We've got a lot of connections in Silicon Valley to tap too for finding hardware partners. I'm not particularly interested in becoming a fab house, unless it's cheaper (including headaches).

Thanks for the well wishes!

We are definitely designing these to support mesh networks, and though I haven't written it down anywhere yet, we're not going to default the radios to full on, that will either be automatically configured (probably too difficult, but I'll look into it) or just manually specified. I would really love to make it automatic though, and for anything under constant comms they could easily communicate their signal strength in the ack if needed to coordinate that. The mesh protocols are still under development (that's what we need Kickstarter for!).

Our wifi + ethernet shield makes it easy to have an always on device that routes traffic for home Flutter networks, but you can also just plug the board into your PC over USB and feed it traffic that way, you can run arbitrary data of any size over the link and all communications are guaranteed (or explicitly timeout), so I think piping TCP/IP over it will be easy.

You can also use a raspberry pi and one of our boards to accomplish what the network shield does (for roughly the same price) but the network shield is designed for exactly this purpose, and many people will find value in that.

It's tough to pitch an Arduino with lots of highly technical capabilities - Arduino users just want to know "but can i make a wireless beer brew setup?" That's the kind of information we try to speak to on the KS page. We're also still learning what questions people have!

Thanks for the reply, Taylor. Perhaps you can explain this to me:

What niche are you guys trying to fill with this? I guess I'm just not seeing it yet. You talk about "piping TCP/IP" over the data link but how is this superior that using any of of the dozens of other powerful, low-cost, mesh solutions purposely designed for TCP/IP routing?

Maybe you're trying to fill the "talk to my kegerator" niche. OK, but how is this superior to the Xbee shield [0]? That shield interfaces with a number of different Xbee products that offer a wide variety of power outputs and ranges. These Xbees do mesh networking out of the box. How does Flutter do it better? Help me understand. :)

[0] https://www.sparkfun.com/products/10854

I don't think XBee is anywhere near that range. Plus, a Flutter is cheaper than an XBee shield + an Arduino.

Anyone bulding remote controlled "stuff" will be delighted.

Yeah, exactly this. Used to be, you buy an Arduino Fio and an xbee module[1], and for $50 you get max 100m range? Two nodes then cost $100, which is enough for one project and one device to route traffic to mobile, lets say.

With Flutter, for $100 you can have 5 nodes, so you can have the beer brew monitoring, control some lights, measure the humidity of your greenhouse, and build a robotic car you can drive with your phone.

We're trying to hit commodity pricing for consumer mesh hardware so people can just toss it in whatever they want to make and easily handle the communications they need.

And not relying on another radio module manufacturer means we can design the product to be everything we need and nothing we don't, and only pay for board manufacture once, instead of paying for a module (which is a manufactured board) that you then put on your own manufactured board.

The radio and cpu should be on the same board and should be very useful (hence open and arduino). Then we can really build a network of things.

You seem proud of the fact that with your $20 pricing you are turning your module into a commodity.

Although I'm sure consumers will cheer you on, I think the typical entrepreneurial thought is that having your product turn into a commodity is a bad thing because there is no money in it.

Do you have a different viewpoint on this?

TCP/IP is a fun idea and I think people will get some use out of it for mesh and darknet purposes, but the target is Arduino users (aka "regular people"). That said, I'm designing the protocol so professionals can use it too. We may end up forking it, and doing what Raspberry Pi did, giving people Rasbian for regular folk and other distros (featured in the same place) for hardcore users.

And you asked why not the shield you linked to?

This is why: https://dlnmh9ip6v2uc.cloudfront.net//images/products/1/0/8/...

That is a $25 shield, $23 radio, and a $29 arduino all stacked on top of eachother, and you get 100m range max. Wouldn't you rather have a single board for $20 or $30 that meets those needs and lets you reach out up to a kilometer or more?

Reply on news.ycombinator.com