I'm also still very interested in this project. IPv6 & 6LoWPAN is still the way to go for me. But although NETMF is a logical choice for me, I'm also looking (or at least peeking) at other platforms that have an IPv6 stack already (e.g. those with a working Contiki port). If I choose to stay with NETMF, getting uIP ported is essential. I've had a look at the inner workings of the NETMF Porting Kit a little while ago, but I haven't yet succeeded to build the Netduino solution without errors. And with lots of other things to do, this kind of moved to the background. Meanwhile, hoping this porting project would get started and I could contribute a little along the way . In theory I should be able to get my head around it all and get this porting project started. I have plenty of experience with microcontrollers, assembler, C, etc. and I really like the challenge . I will have another look at the Porting Kit and uIP.

That is a good find. I couldn't find it either, so I've been looking at the uIP TCP/IP stack that's part of Contiki. The separate uIP stack seems outdated to me, and doesn't support IP6 and 6LoWPAN (which are really important to me). Documentation of uIP as part of Contiki can be found here: http://www.sics.se/~...v6/a01101.html. There's also IP6 and 6LoWPAN specific information there. @hanzibal: I've been looking at the porting kit as the way to incorporate the uIP stack in NETMF. Is this the direction you were thinking of? I'm still having some trouble compiling the NETMF for the Netduino. Does anyone here have experience with that?

Hi guys,

Just a quick post to let you know I'm almost ready to start porting. The only thing between me and NetduIP is a 2 week vacation.

I'm done 'playing' with the Netduino and got familiair again with basic electronics, PWM, ADC, steppermotors, LCD's and so on. I wrote some posts about it on my blog. There are a few posts left to write during my vacation. Which I'll need to publish afterwards, as my laptop is staying at home on my wife's orders .

So, who is or will be contributing to this project as well? And who is volunteering for testing? I don't think I can, or should, take this on alone. I need some people to brainstorm and think together with about how we pull this off. E.g. how close do we stay to the original uIP? It's written in C, we're working in OO, and as Szymon already mentioned, we should leverage what's in NETMF already. And what's the best way to incorporate it into the NETMF/Netduino firmware? How do we support different hardware/shields and make others able to support more? These are just a few questions that came up and that I would really like to talk about with a few people.

And talking about hardware. I have a Netduino Plus, so I'm mostly set for networking with that. But I don't mind ordering some more hardware to be able to test NetduIP on a few other configurations. Like a 'regular' Netduino and the Mini with some of the available shields. So can you guys tell me what hardware you are using? That way I can decide on what to order. Thanks.

Another odd thing I just noticed, is that the interleave steptype does not provide a proper cycle. There are 8 stages in the switch statement that determines which coils to activate (at the end of the OneStep method). Using the interleave steptype, all stages are used. After stage 7, instead of restarting at 0, there is a stage 8. For 8, there is no case statement, so all coils are deactivated. This is also very noticeable in the rotation of the steppermotor, as the rotation isn't smooth and a full 360 degree rotation isn't completed while it should according to the number of steps. Anybody else noticed this?

First of all, thanks guys! This thread has been very helpful getting my motorshield and steppermotors to work. One question though. Could it be that the single and double steptypes are swapped? I'm assuming single means activating a single coil at a time and double means activating two coils at a time. The code does exactly the opposite. Also, I can't get the microstep type of operation to work. The code throws exceptions because the part that determines the pwm duty cycles, is accessing outside the boundaries of the microstepCurve array (index 17, while the array size is 17). I tried to fix the code, but I need to get a decent understanding of microstepping first . Has anybody tried this and, maybe, already fixed it? Thanks in advance.

So the number returned by the ADC should not be converted into a single analog value, but into a range of values: float rangeStart = (float)adcValue / 1024 * 3.3; float rangeEnd = (float)(adcValue + 1) / 1024 * 3.3; And the actual analog signal is somewhere in between. This makes perfect sense and, in my case, makes the measurements from the Netduino match with the DVM measurements. I think the trick is, to not get carried away by the number of decimals of the resulting float values. This, of course, says nothing about the accuracy of the number. Especially with A/D conversions.

Hi Mario, Thanks for the quick and helpful reply . This morning I also came to roughly the same explanation, although not so detailed. It's been a while since I've worked with electronics, especially analog. I'm so used to software, with exact calculations and perfect results. If my off software is off by as much as 0.1%, I'm probably thrown off the project! I think what threw me off, was the fact that the results exactly matched when dividing by 1023, instead of 1024. But, as you've mentioned, probably both DVM and ADC are wrong anyway . Thanks again.

Hi all,

I'm using an ADC port to measure voltage (of a solar charged battery). I use the standard 3.3V Aref and the default 0-1023 range. With a voltage divider (5k6 + 30k) I'm able to measure just over 20V.

Logic tells me (as well as some examples I found) I should calculate the actual voltage by dividing by the number of steps (float actualVoltage = (float)adcValue / 1024 * 3.3). Except it doesn't match the voltage I'm measuring with my DVM. If I use 1023 (float actualVoltage = (float)adcValue / 1023 * 3.3) the voltages match perfectly. I first missed the mismatch when measuring the voltage directly at the port, since it's much smaller there. At the solarpanel/battery the difference is more noticeable.

Now, simplifying the problem, connecting the ADC port directly to 3.3V gives me 3.2968 when dividing by 1024 and exactly 3.3000 when dividing by 1023.

Can anyone tell me, what the logic is behind this? Or am I missing the logic here completely? Thanks in advance!

Excellent initiative! I'm in need of IPv6 & 6LoWPAN implementations.

I received my NetDuino Plus yesterday, after it spending almost a week at Dutch customs . I spent last night soldering 2 shields (Moto & BreadBoard) and expect to spend the next few days trying out my first NETMF code and playing with several hardware pieces.

I have many projects in my mind, but the main one has to be home automation. I want to use 6LoWPAN for most devices and WiFi for high bandwidth stuff like audio. For most of the 6LoWPAN devices, I might just use an ATmega128RFA1. But for the ease of development I could also do NETMF with a 802.15.4 radio-chip. Still not sure, my mind toggles almost every minute... . For connecting the 6LoWPAN world to the full IP world and for the WiFi/LAN devices I'll definitely use NETMF/NetDuino. To get familiair with the 802.15.4 MCU/radio chips I've ordered an AVR RZ RAVEN dev-kit, with an extra RZ RAVEN USB stick to be used as a 802.15.4 sniffer. All that's needed now is a 802.15.4-shield .

I'm not yet sure what to do on top of 6LowPAN. I've heard ZigBee is being adopted to use 6LowPAN. There is also a specification for using REST with 6LoWPAN (CoAP: Constrained Application Protocol), which maybe interesting together with a UPnP-like protocol. I do know that I want all my devices to talk IP and that I want 6LoWPAN on my power/resource constrained devices.

I have no experience with NETMF yet, but I do have over 10 years .NET/C# experience. And many years of C/C++ and assembler before that. I have 2 JeeNodes with some plugs, but I find the development experience with Arduino somewhat dissapointing.

I would very much like to contribute to the uIP port for .NET, if I may. Although I do need to quickly get familiair with NETMF and NetDuino first .

A yes for me, definitely . But being a long time .NET/C# developer might have colored my vote... But I also agree that, in a lot of cases, the NetDuino can be overkill. Luckily I know my way around C/C++ and even assembler. However, developing in NETMF using Visual Studio and the debugging capabilities that it provides is no match to the Arduino platform, IMHO. My plan for my home automation project is to use 802.15.4. Preferably 6LoWPAN, but I'm looking at ZigBee as well. For most end-devices I'm thinking about making an Arduino-version with the single-chip MCU/radio ATmega128RFA1, even though that means no NETMF . My electronics & PCB skills are a bit rusty, but are slowly coming back. RF, antenna's & HF PCB design however, not so much .