Just updated to this version of the firmware. Lots of problems getting Visual Studio to recognize the ND+. Basically, it will recognize it the "first" time, but if the device reboots, gets unplugged, etc, then Visual Studio will no longer recognize it (it does not show up under the "USB" device selection in project properties). Only way I have found to workaround it: Go to Device Manager, right click on the Netduino Device -> Update Drivers. Select "Browse my computer for driver software." Then "Let me pick from a list of device drivers on my computer." Select the Netduino device that shows up there and hit next. That (I think) is forcing a reinstall of the drivers. Any other selection just results in Windows telling me I already have the best drive installed, and does not fix the problem. Nothing else I have tried fixes it (including power cycling the ND+ again). This is on Windows 7 x64, Visual Studio 2010.

I've tested it deeply and I've realized that it only happens when I'm debugging with Visual Studio. I added a break point on socket.Connect(...) line and after pressing F10 the program hangs. However, it is important to me to solve this debugging issue.

As far as I´ve tested, the problem of ethernet cable connection has been fixed on 4.2.

At least on my device, I'm definitely seeing the problem outside the debugger.

Chris,
I just wanted to follow up on this to see if you have had any success in recreating this, or if there is anything else I can try to reproduce.

Thanks!

Chris,
Have you been able to recreate the ethernet problem I described earlier?

Thanks,
Adam

Where you able to get a wiki page for this project/relay usage?

Yup - take a look at http://wiki.netduino...lay-Module.ashx

Version 4.1 of the Netduino firmware supports 48kb, where as version 4.2 RC5 can support 56k.

In order to get "without networking" you need to re-flash your Netduino Plus as a Netduino using the Netduino firmware instead of the plus firmware.

Should note that I also think this means you lose the use of the onboard micro SD card slot.

Chris, I've attached a small sample project which I have replicated the problem on.

--snipped--

Chris,
I just wanted to follow up on this to see if you have had any success in recreating this, or if there is anything else I can try to reproduce.

Thanks!

Hi Cabadam,

The memory buffer settings for Ethernet changed in recent updates of .NET MF, so it's possible this is causing the issue you're seeing.

Can you create a small repro which demonstrates the issue? And perhaps we can test it here to see if we experience the same?

Thank you,

Chris

Chris, I've attached a small sample project which I have replicated the problem on.

Basically, it attempts to connect to google on port 80. It also sets a timer for 10 seconds (plenty of time to connect). If that timer fires and the connection has not already completed successfully, it is considered a failure.

I was not running it in the debugger (because I was constantly rebooting the device to replicate this), so I came up with alternative ways to see the result.
If you have one of the serial LCDs sitting around, connect it to COM1. It will write out the IP address once it retrieves it, and then either success or failure.
Otherwise, the onboard LED will flash twice for a successful connection. If it flashes once, that was a failed connection.

To replicate this, I just waited for it to say success or failure, and then hit the ND+ button to reboot it. Just repeat that over and over.

Note: During this entire process, pings are successful (as is the DNS lookup for Google!). It is just the outgoing TCP connections which are failing.

I'm trying to locate a Eagle library/part for items similar to this. I'm basically looking for any variety of non-screw terminal (does not require a tool to insert/remove the wire), needs to be able to handle ~18gauge wire. There are a couple possible ones I found on DigiKey (thisis another).

But, I can't find any matching parts in the Eagle libraries, nor was I able to find one online anywhere. Any suggestions?

Thanks!

Cabadam,

Don´t you have same issue then I? (or I have same as yours..) If you just put the 4.2RC5 firmware, and no app deploy, are you able to ping your Netduino Plus (we should be able to ping it at this moment, right??)? Turning it on with or without the cable connected don´t matter to me.

Sorry, I just now read your post. It does seem very similar in terms of a reboot causing lots of problems - especially now that I correctly updated the .NET Micro SDK and Netduino SDK versions (oops...).

Although - your later posts seem to be referencing that you cannot ping. For me, pinging is the one thing that seems to fairly consistently work...

Hi Cabadam,

Dang, I was hoping that the networking bugfixed in NETMF 4.2 QFE1 would fix that for you.

Can you post a bug report for this on netmf.codeplex.com? And title it "Ethernet never works if not connected on bott up with SAM7X"? We can work with Microsoft to address the issue from there...

Chris

Hmm, OK, few interesting notes. Turned out I was still on .NET 4.2 RTM, not QFE1. I had clicked the link for it, but saw a post date of 2011 and no particularly obvious edits and assumed it was the same as RC4. Closer inspections shows it is NOT (I see the there is a "Works with RC5" reference, and the link itself has changed to be a QFE1 file). I uninstalled the old .NET Micro SDK and Netduino SDK and installed both of the ones currently linked in that post.

That did solve the problem as-stated in the post. The device does now respond to pings after the ethernet cable is plugged back in.

However, it apparently has caused new ones. The first thing my app does is try to connect to a local HTTP server to retrieve the current local time.

On the first startup, this typically(**) works fine. However, hit the reboot button... and more often than not the socket Connect() call just hangs up. Note that no pulling of the cable was involved - just a reboot of the ND+. That seems to hang indefinitely from what I have seen. Only way to fix it is to pull the cable (that then causes the Connect call to throw an exception - which my code handles and reboots itself), or to explicitly reboot/power cycle the ND+. During this time when it is stuck, the ND+ is responding to pings, so it is still somewhat responsive.

At first, I thought it might be some weird interaction with the WiFi bridge, but I removed that and plugged in straight to my router and the behavior did not change.

I just tried a test run of rebooting the ND+ 10 times and seeing if it connected or not (rebooting by pushing the reset button). 3 times it started up and connected successfully. 7 times it hung on Connect(). Ouch...

** I have actually seen this behavior on a power-cycle (pull out the USB connection, reconnect it) as well, so it may not be specific to a reboot.

Since the behavior of this has changed - I wanted to confirm if you still want me to open a ticket over at codeplex, or if you had any other ideas to try first.

Thanks!

Chris,

Unfortunately the same bug network bug I found previously still exists in RC5. The same steps in the first post still recreate the problem.

http://forums.netdui...ted-on-boot-up/

I had an issue were my Win7x64 machine would reboot if I pulled the USB to the Netduino+ out. This occurred even after reflashing the N+ with MF_DEPLOY. I noticed that during the install of AMTEL SAM-BA 2.11 that Win7 popped up a warning message about the driver that was going to be installed. I subsequently UN-installed AMTEL SAM-BA 2.11 and restarted the PC. The reboot PC problem is no longer present. Must be the SAM-BA driver.
EDIT: the REBOOT PC problem still exists if I pull the USB plug out during a DEPLOY hang.

If you are not already, try using the 4.2 drivers available here: http://forums.netdui...-for-net-mf-42/

How big is the application you are trying to deploy?

Chris, I sent you a PM regarding possibly testing RC5. Thanks,

Probably I was sleeping when I was writing my post above: where am I invented 24VAC???

You should clarify better what's your target. If you mean driving mains, then it's not the TRIAC the problem, but the isolation of the circuit. If you take a look at the shield schematic, for instance, you'll see that there's no isolation between the MCU and the TRIAC leads (i.e. mains).
We might forget that never ever a similar circuit would be approved by the safety laws, but that is one of the simplest way to damage PC or else if the ground wiring isn't properly connected. I'd also add that it could be dangerous for the human health.

If you are dealing with voltages, AC or DC, above 30V, I wouldn't think any second more on choosing a SSR over any hand-made surrogate. A SSR is about $5, not $50: what's the problem?

No no - 24VAC is correct (subject line is where you invented it ) I have no desire to play with 'main' power with my level of experience. My comment regarding the schematic ErikN referenced is simply how many fewer components are involved in that method vs the SSR schematic.

My ultimate motive here is not cost related at all. Rather, I'm hoping to reduce the form factor of my project a little bit. My current hardware I'm testing with are standard electromagnetic relays. I have an 8 relay board and a 2 relay board for 10 total relays.

As I'm looking how to enclose this and such, I first noted that there was a lot of wasted space in this approach. One of the primary reasons being all the screw terminals. NO, NC, Load for each relay. I don't need NO and NC - I only have one 24V power source, not individual sources for each relay. So that's 10x2 = 20 terminals reduced to one, plus the individual Load terminals.

The next question was what to put behind those terminals. I first went to solid state relays because they are slightly smaller in size, but like regular relays, need a number of extra components. While the original retail boards I have are mostly surface mounted components, my work certainly will not be, so I would like to reduce the component count if possible. As I continued to search around, I came across a couple examples people using TRIAC. And that is basically what brought me to this thread.

One other motivation for me to look at TRIACs was when I came across this project: OpenSprinkler. The schematic for it is available, and a closer inspection shows (in the bottom right) that the design is using a shift register connected to a series of TRIACs to control each of the 24VAC outputs. I'm not sure I am actually interested in the shift register part (although it is an interesting way to getting rid of 10 distinct signal lines out of the Netduino, so who knows...). Looking at the photos of their board, the amount of space taken up by the triac/terminal area is much smaller than what I have now.

Hopefully that gives some insight into what I'm actually trying to accomplish. Based on your initial post, I don't think any of these referenced systems have the isolation you referred to? I'm also not sure what they are doing to achieve the negative current? Disregarding the shift register for the moment, would negative current simply be a matter of turning the Digital I/O pin into an "input" rather than output so that current flows the opposite direction?

Thanks

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!

See, the diagram for that shield looks REALLY simple, which is what got my attention about TRIACs. If you remove the fact that there is an inverter involved (to go from DC back to AC), and remove the splitting for having both the plug and through holes, there isn't much left. Digital I/O -> Resistor -> TRIAC gate. Much simpler than the schematic suggested on the solid state relay page. Is that relay one just overly complex, or is it all actually necessary?

With Running 4.2 RC4 on "A":
If "A" is booted without the Ethernet cable, the network port does not work. This is different from 4.1.

This is in fact the same problem I encountered and created this about. I only have one Netduino, but if that Netduino is unplugged on bootup, it is done. It cannot use the network (until the network connection is restored and it is then rebooted).

I've done no intentional testing with losing the connection at runtime, so I cannot say I replicated those scenarios.

I'm anxiously waiting for RC5 to see how much of this is fixed. Chris referenced multiple bufixes related to networking in post #9 above, so I'm hoping that resolves this.

I was looking at solid state relays, such as: http://www.sparkfun.com/products/10636
They have an example layout that includes a number of additional components including 3 other resistors and a transistor. (I'm excluding the LED and its resistor as that is understood and useful).

Take that, and then compare to a diagram such as: http://www.flickr.co...57603835280870/

It is based on Arduino, and basically just needs 1 resistor on the signal line.

Take then a TRIAC such as: http://search.digike...L401E3-ND/13106

The specs on that TRIAC seem to match up, needs 3mA to trigger the gate - well within the range of the Netduino digital outputs. 1.3V on the signal line ** unclear to me if it needs at least this or if something higher (3.3V) would break it??

This looks "that simple" - which tells me I'm probably missing something. Am I?

Thanks,

Yeah, I'm going for the vertical one ($4.30 US, which I'm happy about). Haha, hopefully it doesn't turn into a case of "you get what you pay for". Parts are now on order now. Thanks to both for all the help.

Your assumptions are correct - in the US, and yes, it is a simple 120V to 24V transformer.

So the average voltage of the DC might be within specs of the 35V capacitor, but there are peaks in the ripple, which are what could blow the capacitor. No need to have that! AFTER the capacitors, those peaks should be reduced much closer towards the average.

I'm not doing too bad on this project so far by my standards (killed 1 transformer, and blew fuse in my multimeter - both my fault and I know why), no need to add to the list if I can avoid it!

I've updated my plan to include two capacitors. Both rated at 50V, one higher capacitance near the bridge, one lower (22uF) near the TSR-1.

Speaking of the TSR-1, I started looking around at where I might by that sucker. Three places came up - one won't tell me how much shipping is until after I place the order - which is non-cancellable. One wants just under $20 shipping. And one website doesn't seem to want to let me actually order it.

I started poking around on Digikey (which is where I am getting the capacitors I think), and I found this:
http://www.murata-ps...er/oki-78sr.pdf

Seems to be similarly efficient and shouldn't need a heatsink - also gives me slightly more wattage than the TSR-1. I think that should do the job. The datasheet seems to suggest I might not even need the 22uF capacitor (although it says it can be added if really needed). I'll probably leave it in anyway.

Do you see anything wrong with it as a replacement for the TSR-1?

OK, getting back to this now.

I've decided to kind of split my approach to this based on your feedback.

Short term: I just want to get this working. I purchased a 5V (3A) wall plug. So, now I am providing two separate power sources (24VAC and 5VDC), but I've got everything wired up to it, and it seems to be working great. The 5V components are all split directly off of the wall plug - not going through the ND+, so there isn't any concern about sending too much current through it. It also means I'm not using the ND+'s linear regulators, which helped drop the power usage a bit too. With every 5V relay turned on (something I'll never do in practice), I'm still only at ~6.6W. Way under the 5*3=15W provided by the 5V adapter.


Longer term: I've been playing with the Eagle software to work up a design to provide my 5VDC power directly from the 24AC, instead of requiring an extra wall plug. I'm using the TSR-1 you recommended. As this is the first time I've tried to put components together like this, I wouldn't mind a sanity check.

There are two concerns I had when I designed this:
1) The capacitor and voltage rating
Ignore the rating listed in the Eagle part, I'm assuming I can pretty much stick whatever capacitor I want in the same location - I just needed a part. The real one I'm looking at is one I can pick up locally (Radio Shack part number listed). It is 35V, 1000uF. Paul - you mentioned the 24V AC would rectify out to about 34V DC. That sounds dangerously close. I was reading this post which said it would actually come out more towards 30VDC, which is a LITTLE more breathing room. Is that still too close? If I need to step up to a larger capacitor, I can and will, it would just be nice to not have to order and pay shipping on tiny cheap parts

2) Dual purpose capacitor?
I initially added the capacitor to smooth out the ripple from the bridge rectifier. Looking at the datasheet for the TSR-1, it says there should also be a capacitor coming in if the input voltage is >32VDC - again, very close to where I am. Would this capacitor satisfy both requirements (it looks like it is connected into the same place), or does there need to be two separate capacitors connected in parallel?


If this all works out sensibly, I'll grab the parts and test on a breadboard, but I've also done a board layout for this that I'll probably send to something like this service - seems cheap for this small of a board.

Appreciate any feedback you guys have.

Thanks!

Sorry for the delayed response. Been harder for me to focus on this the last couple days, work got busy!

I'll re-read in some more detail later and respond to some of the other comments, but wanted to give a quick response.

The 24VAC is being used by other components, but I am NOT using the 12VDC elsewhere (well.. I am for this, but it will actually accept 5-15V, so downconverting to 5V wouldn't (shouldn't? ) pose a problem.

In fact, I've noticed the wifi bridge tends to run rather warm, so dropping to 5V might benefit it as well.

I've been exploring lower voltage options and it actually looks like the simpler option for me might end up having a separate outright 5V power source (that just goes directly to the wall) rather than trying to drop and convert my already available 24VAC source. I'm trying to stay towards "ready-made" components because I do not know enough about how to put together these things. 24VAC -> 12V DC was easily available, so that is what I was using. 24VAC -> 9VDC (or even the lowest 7.5VDC) is not something that I could find. I could try to get another adjustable DC->DC step-down regulator, but I had rather bad luck with the first one I had (which is what prompted this whole topic), so I'm not sure I want to go that route again. On the other hand, there are all sorts of 5V wall adapters. I was trying hard to keep my system to "one plug" but that might not be worth the trouble. Of course, if I end up at the 5V route, I just supply power to the 5V components independently - not through the Netduino, and then the heat doesn't even matter anymore.

Wow, great details Paul!

I thought this was really obvious until I took a fresh look at each of the pages you linked. If you're not sure, then the doubt starts to creep in

Yeah, that was basically what happened to me. Thought I had an idea, until I looked around to verify the details. Then the more I read, the more I was unsure I actually understood it.

The 200mA figure comes from the ARM datasheet, page 14: the total current drawn by all the I/O lines cannot exceed 200 mA.

Gotcha, so in terms of powering other components via the 5V or 3V3 pins, the 200mA is not a value I need to concern myself with.

The 80mA figure from the comparison page is the current taken by the Netduino plus when it is actively running a thread, but without any peripherals attached to it. I am 99.9% certain that the current would have been measured on the 5V input.
However since the Netduino uses a linear voltage regulator (not a switching one) for converting Vin to 5V, I think you would see almost the same current being drawn if you supplied 7 to 12V on the Vin pin.

Interesting - OK, learned new tidbit about linear vs switched regulators. Iin ~= Iout. Check.

The 800mA figure comes from the amount of current the regulators can supply. The data sheet for the MD33269DT family of regulators page 1 says Output current in excess of 800mA.
But you can't take 800mA from both regulators (at the same time) because the 5V regulator supplies current to the input of the 3.3V regulator. Hence this has to be the total current from the 5V and 3.3V pins combined.
Also note that if you are supplying your power from USB, the limit needs to be reduced to 500mA as this is the maximum you can draw from USB.

Ah, they are connected in series. So the 3.3V pull will affect the 5V - which is probably fine, the 3.3V current is pretty trivial. My power is not coming from USB.

Since you are supplying power at 12V, over half of the power consumed by the Netduino will be wasted as heat in the 5V regulator. If you can, it would be better to use a lower voltage.

Right now I am in fact using 12V, although I'm exploring some options to reduce that a bit. It sounds like I'm pretty safe on the current, possibly with a little wiggle room (there is a vague chance the 5V number might go up ~50mA) - especially if I can get the voltage down so heat doesn't start building up.

Thanks for all your clarifications - they were a lot of help. And hopefully I understand enough about this that I can sort this out myself on my next project.

I searched around about this, but couldn't really find everything I was looking for in the same place, and in a few places it seems to contradict, so I wanted to try to get clarification.

My questions in this post are relevant to the 5V/3V3 pins - not the various I/O pins.

First the general case of what I can safely power through the 5V and 3v3 pins:

The ND+ tech specs says:
"microcontroller max current: 200 mA total"

Is that the maximum the ND+ will draw for its own purposes (not for connected devices)?

This wiki page says the ND+ draws 80mA when active. Is this incorrect, or does that mean the previously mentioned 200mA is actually how much can be powered in all? In either case, at what voltage(s) are the 80mA and 200mA measured?

This wiki article introduces another value - 800mA for the DC outputs. But again - would that be at 5V or 3.3V (or each??)?

In this specific case, I have three things I'm intending to power:
1) ND+ = ?? mA @ ?? V
2) 60mA @ 3.3V
3) ~175mA @ 5V

I initially had the 5V piece pulled off as a separate step-down regular split off from the same 12V source that was powering the ND+. It worked fine for a little bit, output voltage seemed stable in my testing. But - saying it was cheaply made would be an understatement (this was a "retail" component - not something I made. Cheap, free shipping, seemed to do what I needed). However, it no longer outputs any measurable voltage, so I'm hoping I can actually get away with powering everything directly through the ND+ and simply remove that extra component.

Thanks,