Hi,
is it possible to set the network configuration during runtime?
I'd like to avoid having to use MFDeploy just to set the name of the WiFi to connect to.
Frode

  | ||||||||||||||
Set Network settings during runtime?
Started by Frode, May 24 2015 06:01 PM
22 replies to this topic
#1Posted 24 May 2015 - 06:01 PM Hi, is it possible to set the network configuration during runtime?
I'd like to avoid having to use MFDeploy just to set the name of the WiFi to connect to.
Frode
#2Posted 24 May 2015 - 07:18 PM
Hi Frode,
That's a really great feature idea. If we added support for Wireless80211.SaveConfiguration (i.e. you could change the SSID and then re-save the configuration) would that enable this scenario for you? We're finishing up Netduino.IP for Netduino Plus 2 right now, but I can put this on the summer feature request list. Chris P.S. another option for you if you need this is a hurry...all the source is there if you want to dig in and add this functionality using C# code. There's a single chunk of code in the CC3100 driver during the Initialize(...) function which reads out and the replaces the current SSID info. If you want to reflect into that, you could actually set the runtime config today without having to modify the firmware (or you could use a debug build of the firmware and edit the managed code driver and then just deploy networking at runtime). Gotta love managed code #3Posted 24 May 2015 - 07:35 PM
Frode--one other thing to be aware of... Whenever you change the SSID/passphrase, this rewrites a chunk of flash. And flash storage, after 1000s or 10,000 of cycles, can eventually wear out.
This is not an issue for regular use case scenarios or if you only occasionally change the AP settings. Just be sure that you don't rewrite them unnecessarily (i.e. don't rewrite them every time your app starts, etc.) Chris #4Posted 24 May 2015 - 07:49 PM Hi Chris, thanks for the reply.
If all the settings that we set via the Network dialog in MFDeploy was also available via code, then that would be valuable. It would for example allow us to save the SSID, password, encryption type etc on a SD-card, and use that when booting the Netduino. For now I'm just playing around with the Netduino 3, so I'm in no rush.
I see what you're saying about the flash-writes. That means we should only write new network settings if they have changed. Which would also require us to be able to read the current network settings to see what is currently loaded into the board. Something like Wireless80211.GetConfiguration() would be needed then. #5Posted 24 May 2015 - 09:06 PM Storing it if flash doesnt sound so nice, should either be with the code, or store it on the microsd or something, I was planning to use it to connect to other networks, not ideal if you need to reflash it like that.. hm... -- #6Posted 26 May 2015 - 06:02 AM
Hmmm... This is an issue taht I was not even thinking of. I'm wanting to use a Netduino 3 WiFi for a project and if I cant change the SSID/Password at runtime then that just kills the project. I think I will go to Amazon and cancel my order before it ships. I guess I go back to my original design and use a Fez Cobra II WiFi board or a Raspberry Pi.
Roy #7Posted 26 May 2015 - 06:14 AM
Would you guys like me to see if we can put together a wrapper class, to change the Wifi SSID/passphrase from code?
Chris
#8Posted 26 May 2015 - 08:39 AM
That would help a lot. I'm really wanting to use the Netduino specifically because of the low power nature of it. I guess if I have to I can always go with an XBee S2 on both ends. This is just a sensor application so bandwidth/speed is not a big issue. Initially I was just going to use UDP broadcasts of the data to anyone that was listening.
Thanks
Roy #9Posted 27 May 2015 - 03:43 AM
Chris, yes, that would be nice.
#10Posted 27 May 2015 - 04:22 AM
Roy, Frode:
Would you mind submitting this as a request on the github site? Then we can put something together for you (either as a core update or as a wrapper class that uses reflection internally). Chris #11Posted 27 May 2015 - 08:22 PM In which Github repository should the issue be created? This one? https://github.com/netduino/netmf #12Posted 27 May 2015 - 08:25 PM
Let's use this one (the CC3100 hybrid stack): https://github.com/n...duino.IP_CC3100 Thanks Frode, Chris #14Posted 28 May 2015 - 01:33 AM I started working on this before I saw that we would get a wrapper....
It looked like the following would do the trick:
// Set the static public initialized field to false so that when we later invoke Initialize it will short circuit return CC3100SocketNative._isInitialized = false;
// On the static public _cc3100 instance, add the wireless settings. I'm a bit lost on priority without looking further CC3100SocketNative._cc3100.sl_WlanProfileAdd(ssid, null, securitytype, securitykey, null, priority);
// Re-initialize CC3100SocketNative.Initialize();
After catching up on the thread I decided to call it quits otherwise I would have forged ahead and whipped up a pull request once I got it working. The place where I'm most stuck is how to actually test the above. I don't even have a Netduino.IP in my references or sdk. I think I'm missing something silly.
Sidenote - I was quite surprised that the class fields above were public. #15Posted 28 May 2015 - 02:31 AM
Hey Brian,
Netduino.IP is actually called internally by the NETMF networking classes. That's why you don't need to reference it manually in your code. We wanted the implementation to be completely seamless/transparent. That said...if you work with a version of the firmware that doesn't have Netduino.IP compiled into it...you can add Netduino.IP and the other networking assembly projects to your code...and then interactively modify and debug the networking stack in Visual Studio. Chris #16Posted 28 May 2015 - 07:25 PM OK.. Since Chris expressed some interest in getting this to work at runtime I went ahead and left the Amazon order in place. I now have the device and once I get it all flashed and updated to the latest bits I'm going to start working with it.
Just a side note on power. I wanted to do an initial test of how things look from the start with no code or load on the device.
Netduino 1 Plus : 5.10v/0.03a (0.153 watt) Fez Cerbino Bee: 5.09v/0.04a (0.205 watt) Netduino 3 : 5.08v/0.07a (0.355 watt) Fez Cobra II : 5.05v/0.17a (0.859 watt) Raspberry Pi 2 : 5.01v/0.32a (1.603 watt)
Ii I have to go past the Netduino 3 then I might as well go with the Raspberry Pi because I will need to have dedicated power anyway so would just use the ethernet port (w/PoE adapter).
Roy
#17Posted 28 May 2015 - 07:32 PM
Interesting idle power numbers!
The Raspberry Pi 2 will need much more power than that during actual use I even had some trouble powering mine with a 1A USB adapter. Also, I don't have actual numbers for this, but power usage on the N3W does shoot up a bit during Wi-Fi operations (as you'd expect). Still way less than a Pi, though. How are you measuring this, did you just cut a USB cable? #18Posted 28 May 2015 - 07:41 PM
I'm sure they will go up once load starts getting put on them. These were just initial numbers to see if I was even going to be in the area I needed. I can go up to about 0.5 watt buts thats about it. I used a simple "charger doctor" from Adafruit to get the numbers.
https://www.adafruit.com/product/1852
Once I get some load on the WiFi I will measure again to see if I am within limits.
Roy #19Posted 28 May 2015 - 07:42 PM
I run my Pi 2 headless and I find it's using about 280mA - 320mA under a reasonably normal load. The number is as shown on my bench power supply, I've been experimenting with a backplane capable of supporting four Pi 2's on a single power supply. Voiding all warranties as you'd expect...
Regards, Mark To be or not to be = 0xFF
Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life Follow @nevynuk on Twitter #20Posted 28 May 2015 - 07:49 PM
Oh, interesting! I hadn't seen this product before. I see they also have this, which would allow you to connect it to a (probably more precise) multimeter: https://www.adafruit.com/products/1456
It's possible that the adapter I was using was a bit dodgy, too -- I really should take some actual measurements to confirm. 0 user(s) are reading this topic0 members, 0 guests, 0 anonymous users | ||||||||||||||
|
||||||||||||||
This webpage is licensed under a Creative Commons Attribution-ShareAlike License. | ||||||||||||||