Please give it another shot. I think it was blocking all non USA traffic because of some spam I was getting from China a while back.

Ah yes, the sledgehammer approach.

Just wanted to report that I had my first successful test of my project in the field on an investigation of an old tavern Saturday Night.

Congrats!

This was also my first test of the new LiPo battery circuit and the charger and it worked fine.

I looked over your project site but I didn't see anything specific about this. I'm curious - what are you using? Custom build? I just picked up a couple of these from Adafruit and I've just started testing them. So far with default configuration I was able to charge a LiPoly battery and blind myself with a 1W LED on the circuit output from a MacBook Pro USB port. The board says it can do 1A but I believe the default is 500mA.

I didn't run the LED for very long, I just wanted to test the transition from USB pass-through while charging the LiPoly to running from the LiPoly pack.

Wish I could be there! I've only been to one so far, NYC last year. And I'll be going again this year. I just think it'd be sweet to see how the west coast Faire differs. EDIT: Awww Man! Adam Savage will be speaking at the Bay Area Faire. /sad_panda

But big chance I will be at maker faire NY in September!

Sweet! Or as they say in your language, dit is echt het meest opwindende nieuws!

Artist? I was thinking about just the logo on the front, maybe on the back, pretty simple

You should consider an easy-to-read/remember shortlink or QR code for those too shy to ask about it. Make it easy for them to see or secretly scan to keep it on record to look up later!

Awesome job! Can't wait to get my compilers on it!

I am eagerly awaiting my LCD module! In fact, I just got an email from my apartment building saying I have a UPS package waiting for me when I get home. I have a couple things on order and the tracking info only shows me from where the package was shipped. The anticipation is killing me! It could be my order from [nwazet or fancy shampoo! Edit: Looks like it's the LCD module (and sundry)! But now I need more cables...

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.

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

I thought this was a known issue. I remember seeing a reference in the latest 4.2 firmware that says ethernet can not be plugged in at any time and is no longer required to be connected at boot-up. If I am remembering correctly, this means the 4.1 releases require the connection at boot time.

EDIT:
Oops, I didn't realize the latest 4.2 was up to RC4 and since I didn't see an explicit version mentioned, I assumed you were using 4.1 - looking at the error more closely I see you are using 4.2.0.0. Looking over the 4.2 RC4 features and sure enough that's where the first mention of plugging in the ethernet at any time is mentioned.

This firmware also includes the following previous updates:
...
5. Network cable may now be plugged in at any time

This is what you'll see if you don't have a proper static main() method to start/run your project. Did something happen to it?

I'll be in Times Square! I'm looking forward to it - there's been some talk about people dressing up as Martians. I'm not sure how to go as fossilized remains so I might sit the cosplay out.

Hearing the crowd cheer almost simultaneously was pretty worth it.

+eleventy

I don't know if this'll put a damper on things - but it just opened up some heavy rain over my apartment! I'm 3 blocks away from the event location in Times Square.

I think you could pull off the dark wizard look quite easily! I'm interested to see what you come up with. I've seen the "Blade Runner" style umbrellas before but they've always seemed too weak to use in any sort of ambient light. As further ideas, I think having a button to immediately switch to a red and orange swirling pattern would be useful to you. When you get angry you can hold the button down and switch into this mode to look extra menacing. When you've calmed you can release and let the colors go back to swirling through a fuller range of color.

Some of us were very lucky to have a mild rain and not lose power. Just a few blocks made all the difference for some. Of course we still suffer in our own way - by having to continue to work! It was a small price to pay to keep things running while those who suffered the real damage had the time to recover. I'm grateful those I know around the various parts of the city went mostly unharmed if inconvenienced by the power and service outages. The one exception was a coworker who lives on Long Island - he lost his house ("I have an indoor pool now!") and his 3 cars. He has had to relocate and is working remotely from his son's house. I can't imagine that sort of disruption.

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

I made it out unscathed too. I had a couple flickers but never lost power. During the worst of the storm I was in Times Square live casting and buying cheesecake.

A nice lady from PopSci stopped and chatted with us at the event...

She just posted her article, and Erik got a mention.
http://www.popsci.co...-53-foot-screen

Best of all, after two weeks...Curiosity is still making big news. Awesome.

Thanks again to all those who joined us online or in person to celebrate this historical moment.

Chris

I'd just saw this earlier today. I have no idea why it popped into my head to go looking.

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.

I remember talking to Arron about this a little while ago. Looking at the circuit it certainly seemed possible by coincidence but it looked like it was not designed that way. When powered "correctly" there seems to be a lot of effort put toward clean power and keeping selfish components from affecting the stability of the power. When supplying power from a module - this is all bypassed. You'd need to be very careful not to supply dirty, reversed or spiky power. Chris popped in to catch the tail end of it and ended the conversation with an abrupt: "Don't do that.*" I suppose if you have a large supply of Go boards and don't mind some waste - go ahead! But if you only have one precious, treat it kindly and power it as designed. *I think this was the direct quote. It's been awhile though.

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.

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.