I haven't worked with them but if the modules do have the ability to be put into a sleep mode, exposing the ability to control that would seem pretty useful. I'd think waking up to do a status burst every so often would be a common scenario.

Hey everyone - I want to say I spoke to Antti directly and worked out the language difference. I can say with absolute confidence the initial communication was just a misunderstanding but there was some escalation after that point with the frustration. From Antti's point of view there was some sense of being attacked where I can see the remaining members were probably being defensive to what they sensed was an antagonistic contact. Please take my word that this was just a misunderstanding. Antti's use of the English language seems so complete it's easy to overlook that he's not a native speaker and is from a different cultural background. The way the language is learned varies greatly around the world and leads to misunderstandings like this when people don't realize they're speaking with someone with such a different background. I hope everyone involved can stop and reset their perception of each other from this first impression! Antti: While I do not speak for Secret Labs or the talented people involved in the Netduino Go project, I can say with confidence the source will be forthcoming. It's important to understand the resources involved in this project are quite small given the scope. Due to this a lot of things slipped through the cracks. I can say I'm never as good with documentation as I am with getting to the 90% point of a project. This is not an excuse. The open source hardware, in fact open source in general, has a difficult time with the last details of a project. Please don't think this means something strange is going on. Secret Labs has committed quite deeply to the open source hardware and software communities. From what I can tell, without passionate people external to Secret Labs, the Netduino Go would not be where it is today. Because of this immense accomplishment, despite the remaining community member's desire to have the SDK completely finished and released, we are very tolerant. This is a brand new product. This is a new league of device. It will take some time for everything to come together. Please also keep in mind the Netduino Go is not even finished being made yet! The same limited resources that rushed to get this amazing hardware to us are still working on refining the SDK to get the most stable and best performing firmware and libraries out to those of us on the bleeding edge who wanted to get our hands on this project early. They are still working on stabilizing the Shield Base module and preparing the switch over to faster bus access for it. They are working with a small group of extremely dedicated and passionate people who want to start creating go!bus compatible modules right now. It's important they pursue these goals now while the community is at the height of their excitement or they might lose the momentum and struggle later to get people interested again. This is important to us in the community because we need those passionate people to struggle through the rough ground and cut a path for us! We need them to shake out the problems and establish a common, workable way of creating modules. In short, please allow for some delinquency in the schedule. It was very ambitious of them and things slid. Updating a web page to reflect this was clearly an oversight. As Secret Labs people can't possibly monitor the forum so frequently to see that this is an issue and correct it immediately, it will take a little time for this to shake out. If it is acceptable, please just consider the date "pending" but know that it will be as soon as is responsible. In my time here I have grown to understand Secret Labs to be full of wonderful, passionate and very smart people who will help in any way possible. They are committed to delivering high quality boards. If you look at the schematics and see how well the boards are engineered with respect to signal and input tolerances, the components chosen for the manufacture, and with the Netduino Go the commitment to using easily recycled parts to lessen their environmental impact, I hope you will come to see them as I do: a truly great, caring company. My best, -Erik

This is not a helpful teaser! I've threatened to chain up Stefan unless he tells me but he hasn't cracked yet.

I'm running the wcf service in visual studio debug mode in visual studio 2012.
I'm running the netduino in debug mode in visual studio 2010.

Both on same computer.

While your VS instances are on the same computer, you Netduino is an external device. Usually VS doesn't not allow remote clients to connect to services it is hosting directly. I'm unsure if this is a setting that can be changed in Visual Studio directly.
I know you mentioned unblocking ports - is this from within VS or a firewall on your host computer? If it's a firewall, then VS itself is denying the connection attempt since it's coming from a client external to itself.

I really test this you'll have to publish your WCF service to an IIS virtual application or see if Visual Studio can be set to permit external connection requests.

Is glass not the best option? I would think it would have low-to-no reaction to the water and - assuming the temperature probe were in direct contract with the glass - it should react fairly quickly to temperature change. Maybe you could just get a long test-tube, affix the sensor to the side near the bottom and submerge. Keep the open end above the water line and cork it. Isn't this how most aquarium heaters are built? For reaction time, I'd try to have the smallest amount of air volume possible - so maybe after affixing the sensor you could use a silicon seal just above the sensor to insulate it from the remaining air column in the tube/vial? This approach should keep everything except the glass completely away from the water for both electronic and fishy health. -Erik

Maybe it'd be a good idea to heat the tube to expel excess moisture in the air and possibly draw a bit of a vacuum when you seal it. That will further reduce the air volume and help eliminate condensation from affecting your board and causing corrosion. Alternatively maybe you could drop in a desiccant packet from a pill bottle if you don't want to heat blast the tube. Either way, I think it's a good idea to remove as much moisture from the sensor area before you seal it.

I've had pretty good success with running WIndows inside VirtualBox. After you've connected the board you need to go into VirtualBox settings, USB and add a filter for the Netduino device. This should cause the Netduino to automatically (re)connect to the VM instance when it is plugged in / rebooted.

 

Sometimes a deployment will fail or time out. Usually I can just right-click on the VirtualBox USB indicator in the status bar and click the Netduino device to disconnect it and do that again to reconnect it before trying to deploy again.

 

It's not as smooth as just using a native Windows environment but it's not bad either.

You can't do this with a single thread. You'll need to use 2 threads (and probably want to synchronize them in case one rushes the other by a little bit; otherwise the time difference could grow greater and greater with each loop.) I'd do it like this: MainThread: Prepare things [PWM ports, semaphore or reset events for synchronization] Create 2 threads; one to execute the dimming of LED 1, one to execute the dimming of LED 2 (possibly the same method but with invert parameter?) Methods loop forever just changing brightness of their LED. Start both threads. Thread.Sleep(Infinity); To prevent their timing from drifting use thread signaling. Have each thread block and wait at the end of their loop until the other thread also reaches their end before letting the loop restart. You could use two autoresetevents - one for each thread? I'm not sure if there's a potential for deadlock but I can't see how (assuming you call Set before Wait) but you could attempt to avoid it with a timeout in the wait.

Ah, I misunderstood. I thought you were trying to achieve the CW2's second timing diagram.

Also true. I'd thought about that this morning. I tend to over-complicate things I guess.

SparkFun has a couple EL Wire controller boards which use Triacs to switch high frequency AC from an inverter to the wire. One model has a microcontroller on board and the other is meant to be used as a shield.

I've never looked at the schematics to see how this differs from what I know about SSRs so this is presented as informational and entertainment purposes only. If you learn something it's your own fault.

Enjoy!

I was at the booth for a short time yesterday and from overhearing just a few people it was clear people were very happy to know they could use just one board and the hub to use all the modules. It would seem there was some frustration with the number of choices out there. The dilema of choice. I'm incredibly excited to see a unifying solution! I really think this will be overall a very good thing for users. Kudos.

I think hans polders' guess is my favourite so far in his recent Tweet.

@MyNetduino, guess a new board with the name Netduino Kal-El, Runs @1Ghz, 2 cores, produces power instead of consuming and hates kryptonite

Hmm - "You have been blocked from following this account at the request of the user." But I can see the posts. Weird.

V2lsbCB0aGUgU2hpZWxkIEJhc2Ugc3VwcG9ydCBJMkMgdW50aWwgRmViIDIwMTM/IEluIHByZXNl
bnQgc2l0dWF0aW9uLCBJIG5lZWQgdG8gY2hvb3NlIGJldHdlZW4gc3BlZWQgYW5kIHN1cHBvcnRl
ZCBpbnRlcmZhY2VzIDotKA==

Asking questions this way is unlikely to get a response. I think people are getting burned out on the encoding!

Decoded:

Will the Shield Base support I2C until Feb 2013? In present situation, I need to choose between speed and supported interfaces :-(

Q2hyaXMgd2lsbCBwdWJsaXNoIGEgdmlkZW8gb2YgaGltc2VsZiBzaW5naW5nIERhZnQgUHVuayAt
IEhhcmRlciBCZXR0ZXIgRmFzdGVyIG9uIE5vdiA4IHVzaW5nIHNvbWUgbmV0ZHVpbm8gYmFzZWQg
c3ludGhlc2l6ZXIuDQoNCkRhZnQgUHVuayAtIEhhcmRlciBCZXR0ZXIgRmFzdGVyDQpodHRwOi8v
d3d3LmJpbmcuY29tL3NlYXJjaD9xPUZSQTE4MDUwMTY2MA0KaHR0cDovL3d3dy5nb29nbGUuY29t
L3NlYXJjaD9xPUZSQTE4MDUwMTY2MA==

Now THAT I'd pay money to see!

I'm super in love with today's new clue. If I've interpreted it correctly. Though I'm not sure to what it's referring, I like the message. Seems to fit with the secrecy theme too!

Ok - so back to the clues.
People have figured out the gobbledygook was a date.
It's assumed the FRA... is a pointer to Daft Punk Harder, Better, Faster, Stronger.
And the latest: Faster than a speeding bullet.* And a date.

So, what could the asterisk signify? Internet telephony? Is it to denote something shady like when a record holder was found to be doping?
Better, Faster I'm on board with. Those seem straight forward. Harder? Like - more difficult? This is less awesome. Or is it milled from a solid block of aluminum like MacBooks? Those are pretty awesome and would meet with Stronger too.

Put it all together and ... Holy Crap You Guys - Netduino Phone!*
*Not a real phone.

That was a real thread killer.

V2l0aCB0aGlzIE5vci1FYXN0ZXIgY29taW5nLCBJIGhvcGUgd2UgaGF2ZSBwb3dlciB0byBmaW5kIG91dCBvbiBOb3YgOC4=

That's actually a good point!

If this thing has tons of GPIO/PWM's, can I just pre-order now? Please?!

Adafruit announced these 16-channel 12-bit PWM boards a few weeks back. Works on 3v3 logic but says is 5v compliant.
They also have solder joints to use as logical addresses so you can chain 62 of them for 992 PWM outputs.
Looks like they recently went out of stock but should be back soon. And it's I2C. I always forget what the status of I2C support is though. Maybe that's a non-starter?

SSBkZW55IGFsbCBrbm93bGVkZ2UuIEkgZG9uJ3Qga25vdyBhIHRoaW5nLg==

U3RlZmFuIC0gU3RvcCBlZ2dpbmcgcGVvcGxlIG9uISBZb3UncmUgc28gbWVhbiE=

Um, well that's unfortunate and awkward. It would appear that you were accidently blocked. :$ :$ <insert blushing emoticon>

...well at least that's the story I'm sticking with.

You also have a PM with my apologies. Sorry Erik!

Steve

No worries. I'm surprised being blocked means you can still see the tweets but just can't follow. Um...bookmark? Or is that terribly uncool of me to even know the term?

I didn't get to go for as long as I did last year and even last year I missed a great deal of the exhibits! The trains from Manhattan were all screwed up and that ate into our day there. If you've never been, the event space is very big and split into zones. There's a lot to see but I find a great deal of the value is from listening to people ask questions - it really gives you insight into the way other people are looking at particular bits of technology and what they value. There are a lot of talks and presentations covering a wide variety of topics. It's all very family friendly (though they did add a Beer Garden this year). On top of the Maker events, the entire New York Hall of Science is open and you can browse their exhibits. This was the 3rd annual Maker Faire in NYC and compared to last year it seems to be maturing quite well which is amazing since it's already pretty awesome. Except the food lines. Those are emphatically not awesome. I brought some friends this year who previously had no experience with Maker culture. They both found things they were interested in and seemed to have a good time even if it was a short day for us. My dancer friend was really taken in by the acrobatic show and the arts and jewelry. My engineer friend wanted to check out wearables since he works on Augmented Reality in his day job but was disappointed that it was all just conductive thread and LEDs and Floras. He seemed to enjoy looking at things but we didn't have time to listen to any of the talks specifically. I had a ball. Normally I'm not very comfortable in crowded places but there's something about the crowded place being populated by people who all have similar interests that makes it easier. I struck up a few conversations and helped people navigate the nightmare subway system and was still buzzing with energy when I got home despite being completely exhausted. Long story short - it's a great thing to visit. The event is maturing, there is a wide variety of booths, demonstrations and talks to fill up your entire weekend and the people are just about the friendliest and most inquisitive you can find. It's really amazing the type of people you meet in completely random encounters. When I had people coming up to visit me, I let them know it was Maker Faire weekend and attending was not optional. I compromised though and only went one day. I regret it. I missed so much! Oh well, there's always next year! -Erik

The DOD requiurement for the arbitrary maximum is 60K FT Altitude + 1K FtPS Speed. However most manufactures write the firmware code as 60K FT or 1 ftPS instead of 60KFT and 1 ftPS.

My team and I have posted emails to a few of the larger chip makers with what we are trying to do in an effort to get a properly coded GPS Chip that will meet our needs.

Sounds like you've got it covered then!

Is this a good breakdown of what you're asking?

• Can you request a health check from the Netduino?
• Can you extend the program memory size by using an SD card?

For 1, you can do a few things in an attempt to determine if your board is GO/NOGO but I don't know of any single or set of commands you can run to get this answer directly. For instance, I know of no way to say: Check analog pins can input and output relative to Aref correctly, check the onboard LED is functioning, etc. You'd have to identify the components critical to your operation and devise a way to do a system check yourself. When you do this you might find some things can't be tested when the board is connected to your circuit(s) and require a dedicated testing station. You might also find not every test can be run and understood by the board - for instance generating PWM might be hard to measure to ensure you're getting the correct frequencies and you'll need to use an external device to do the proper capture and/or analysis.

As for 2, there are a number of discussions on using the SD card as storage space for DLLs but keep in mind, once you load the DLL into memory, you're using the chip memory. You can't execute program space from the SD card directly. The SD card is primarily used to store log or resource files. I wouldn't count on being able to use this when decided on what boards to evaluate for your needs.

Side note: all consumer GPS receivers (sold in the US? made in the US? required by license?) have an arbitrary maximum operating altitude above which they will be unusable. Just something to be aware of when designing your project.