jmpe

The reason I posted the idea was to start with a system that is working and where you can forego the filesystem and other parts that are typically found on a full blown OS. It's not uncommon for an RTOS to dismiss the GC and leave it to the programmer.

For example, there are discussions in the RTOS world to take a closer look at Rust (Google embedded Rust) which is why the terms "new OS", "GC" and "experimental" triggered my response to look over there for a starting point.

The author could focus on an existing embedded RTOS and fork from there. Enough cherries to pick one.

Nest is wifi, the second generation added 802.15.4 - but I never dealt with the product.

  Pure RF connection cannot be called IoT, right?

You're correct. You always need a bridge to fill the gap between RF modules and the net. Such a device often adds functionality like buffering, keep logs, manage updates and provide a local webserver.

Which is kind of a shame. The internet got part of its breakthrough because it became tech agnostic on the low layers. Token ring? Optical? Cable? twisted pair? no worries, you can hook it up.

SDR could provide a solution in that field. But there's a good chance that patents/licences will be cumbersome, just like the current situation with wifi.

BTW, if you're looking for a good wifi embeddable module: Carambola 2 by 8devices is a solid product. I recently built a WEP-wardriver with one and it took just an evening of scripting and soldering.

Wifi is problematic due to price and power.

Wifi embeddable modules aren't cheap, non-wifi RF are available for peanuts (RFM, Nordic, ...). But you kinda have to reinvent the wheel: the content of the packets is normally limited to 32 bytes and you have to pick/design your meshing network approach. They come in all kinds of bandwidths (normally up to order 2Mbps) and for different unlicensed frequencies which you pick depending on scenario (indoor/outdoor), range and power availability (listening 24/7 won't work on batteries).

But most IoT devices with these modules will keep their protocol closed.

If you need internet connectivity you normally pick cheap RF modules for the web of thing modules and a central module with wifi/Ethernet to talk to the servers.

Bluetooth... I hate that stuff. Zigbee ... I dislike it because most vendors sell it in a UART/RSxxx interface mode (I prefer SPI).

Non-wifi RF: incredible variety of products. Wifi: just a few.

Lastly: Power. Non-wifi RF can run on a small solar cell connected to a uC with 2kb code and 128 byte RAM. Wifi will need a mid-spec uC with a few dozen kb of code to run a minimal uIP stack. Won't run on a small solar cell or battery (e.g. your phone) for long.

Yep, which is why they'll often have constant green, pulsing green or blinking green as different status indicators.

Blue leds are mainly used for novelty value, it was the most difficult color to create in leds and now that we have them ... Some info here:

http://www.youtube.com/watch?v=yusrrOPM43o

A considerable part of the population experiences eyestrain from blue leds. They can induce headaches and when used in the bedroom you risk disturbed sleep cycles or difficulty falling asleep.

The main motivation on my behalf is that it allows us to create synergy with sensors.

Company A sells door/window contact stuff. Company B sells indoor presence detectors. Company C sells plugs to dim/switch/measure appliances.

If they make their communication stack transparent anyone can jump in and combine these products to improve comfort (e.g. appropriately dimmed lights as you walk through the house), reduce the energy bill ("you're running the airco with the window open" or kill lights in unoccupied rooms) or add a level of security ("no presence inside, no appliances on but the window just opened...").

Without it you're limited to the island solutions provided by the service.

Have a bit of experience in this field, on a technical side:

- Always provide a way to auto update and fallback if failed.

- never implement a buzzer or beeper.

- stay away from blue status leds. people really dislike them, especially in the bedroom.

- always design with sleep/low power mode functionality. If it's embedded uC: 1 watt is more than enough, even with RF. Pick bistable relays. If it's a Linux SoC aim for less than 3W. If there's wifi keep it under 21 dBm. Pick sps modules like 78SRxx from murata instead of linear 78xx.

- if it's a thing you plug in the wall socket make sure it doesn't obstruct other sockets.

- expect people to unplug it every moment every day.

- don't force people to provide an email to activate some functionality or feature.

- use open source standards for communication protocols and put yours in a public datasheet with detailed info on how to parse & process.

Not sure why you're telling me this, I suggested MSP430 to the parent post as an answer for the ISA he was looking for.

MSP430?

Check out the FiniteStateEntropy/test/probaGenerator.c code.

It builds a table of character sequences based on a probability. If you feed it a p=0.5 you get a sequence that halves each time:

0000000011111223 (shortened example, the real total length is 4096 so you get 2048x0, 1024x1 ...)

This is then used as an alphabet probability to build random sequences in the test file.

The algorithm scores better than huff for higher P, meaning that the alphabet shortens with a few dominant ones. This means that (statistically) you get a lot of words in your dictionary that resemble each other. And that's where the fractional probability plays its role.

To try to answer your question I'd guess that this technique shows its muscle for data sets in which the dictionary is large and consists of similar sequences. Example: a csv file with a lot of numbers, gis or kml datasets, Gerber files, ...

We always knew that the implementation of these devices incorporated a uC, simply because the way you interact with them (SPI or SDIO interface) involves a state machine that would take up lots of space or upgrade headaches to do in pure hardwired logic.

What a lot of us thought, however, is that the uC would be in the form of what's found in other single purpose devices with similar interfaces (e.g. temp/humidity sensors) : code exists in some ROM table whose mask is set in production.

Secondly, flash is a highly competitive product with narrow margins. Check out some other posts on his blog to get an idea, esp. the ones about the ghost runs.

It's only after you read up on the complexities of bad cell management in flash that you get a sense of this problem. And that it involves complex on-device logic. In the end, the devices (uC) become so high-spec that the firmware update feature is a no-brainer. Compare it to cell phones that increase in complexity until one day they're capable of running Linux, at which point a floodgate of possibilities opens up.

yeah, that line of reasoning totally makes sense. And ~500$ per hour for software ticketing is a reasonable number.

Google loves things that scale, and customer support doesn't scale that well I guess.

Alternatively, couldn't they start a pay-per-minute service? I recently had an issue with GMail where I was receiving someone else's mail. After about a week I had enough data to source his phone number and contact him to rectify it. But I never had the chance to report the issue. Wouldn't have minded paying a few dollars to have that one rectified at the source.

Complex question, but there are a few aspects that work against them:

- coral typically takes several years before reaching sexual maturity. Adaptability to a changing environment strongly depends on this.

- corals typically occupy ecological niches.

- acidification directly interferes with a key part of their metabolism and habit. It's like asking whether mammals can't evolve to a life without skeletons.

Corals are an extremely diverse group of organisms that interact with other organisms through complex relationships. Take them away (or reduce them to a select few species that fulfill a fitness) and you're going to see lots of damage to other populations.

Thanks, wasn't aware of roboy.

You're absolutely correct re clutching actuators. There are a lot of robotics projects out there that combine small devices with limited mobility to create a larger (multicellular) robot with higher mobility. All of these projects stumble on that particular aspect: maintaining a lock without consuming power. M-Tran, Symbrion, Distributed Flight Array, ...

It's coming but robotics has a major obstacle: transferring power to locomotion. Ideally, we'd have something like a synthetic muscle that converts electricity to work. Instead we have all sorts of servo/hydraulics based actuators. Because of this robotics have a problem with elegant design (anything that doesn't run on wheels) and power/autonomy.

There are advances out there, but as long as one can't buy a strand of synthetic muscle for a few dollars it's not going to progress that much.

"Jupiter radiation belts"

Found "Magnetosphere of Jupiter" on Wikipedia and it looks like the rest of my evening will be spent on this little tidbit. How could I never have heard about this.

I imagined that such a geyser has a limited lifespan. Same mechanism as why islands like Hawaii or the super volcano in Yellowstone come in chains. Same thing could be happening on Europa: the icy crust moves and the "hot spot" is fairly fixed. Or a local vent collapses after x years and another weak spot opens. In those scenarios the area surrounding a geyser could preserve a chapter of the planet's history.

Would be cool if they got there and found layer upon layer of carcasses resembling whales, fish, trilobites ... seasoned with smaller organisms. A record of evolution, deposited over thousands of years of geyser activity, perfectly preserved and documenting every evolutionary bifurcation that ever swam too close to one of these blowholes.

I can dream, can't I?

This is an awesome phenomenon. Yesterday we had a post re panspermia:

https://news.ycombinator.com/item?id=6888412

Now think of an Europa with simple bacteria living in the water under the ice. These events are like cosmic sporulation: long strings of frozen droplets that could contain organisms, ejaculated into space like spores in the wind.

  ... without requiring a recreation of an improbable event in all of them

Just to add to your post: the probability of such a spontaneous event (life emerging from a cocktail) increases as you're no longer looking at a restricted area. If panspermia is the mechanism then you don't require life to originate on a suitable planet in a Goldilocks zone. Every square mm of (often porous) rock flying around is a potential point of origin, carrier or seeding station.

This is pretty much one of the Ultima Thules of Mathematics. Reading about it won't make you understand it, the metaphors used in popular science are just that: simple analogies that fool the reader. If you want to understand it I'd suggest allocating 6 years of your life to be thought the foundations and move on from there.

Edited to remove a shitty snark re fractional dimensions, hence the replies.

Memory growth is not a consideration in the academic proof, Turing machine tape is infinite in both directions.

Google groups comes to mind. It's not uncommon to have to wait several seconds before you can read the text, and then it all collapses and you need to fish for the right post.

Carambola-2 with dev-board. No hassle, low price and compact.

http://8devices.com/carambola-2

That's because it is a novelty. You're pretty much restricted to planar circuits with this approach and the resistance is pretty bad.

That's for a large part due to the charging speed itself. If you charge at the maximum allowed current your battery will have the shortest longevity. Most chargers advertise on the capability to charge fast, but for a lot of battery chemistries it comes with that trade off. If you have the habit of charging over night I'd suggest to buy a slow charger or trickle charger. The slowest (optimum longevity) are typically "40 rate" which means (I'm simplifying here) the charge current is 1/40 the Max capacity current and takes about 40 hours to charge.

Note: don't go cheap by buying Chinese crap for battery chargers, especially Li chemistries. Best case: works as advertised. Worst case: electrocution or house goes up in flames.

force from acceleration scales linearly with mass. mass, however, scales cubic with size: something at 1/10 scale is 1/1000 the mass.

surface scales square with scale (something at 1/10 scale has 1/100 surface or cross section surface)

with miniaturization with factor x you get 1/x^3 mass and 1/x^2 cross section surface. as a result stresses (Force/Surface) becomes 1/x less on a given surface for acceleration.

(on mobile, edited a few times)

The hps operates at higher power and comes in models that scatter the light in all directions (so you need a reflector). The spectrum is constrained (as is for led) but you'll find it difficult to change it. All those lumens are in an unfavorable part of the spectrum. LED is much better at fooling our eyes, their spectrum can be tuned to sit close to the receptiveness maxima for our eyes.

Had such a case a few months back. Strings of single-byte characters are Endian-agnostic but multi-byte character encoding is affected by Endianness. To cope with it I read the sequence as single byte, then reversed, then changed the encoding to proper encoding and reversed again. The data came from a binary dump where I only needed a section that contained a few strings.

I admit it's dirty but it was throwaway code for an isolated case.

Edit: eh, guys, as I stated the string came from a binary dump. I didn't get to choose the encoding, it came from ROM in an embedded system with a different Endianness. I had to figure out a way to make it human readable.