- Netduino Forums
- → Scott Green's Content
Scott Green's Content
There have been 34 items by Scott Green (Search limited from 19-June 23)
#21274 Web Based Temperature Logger
Posted by
Scott Green
on 02 December 2011 - 09:23 PM
in
Project Showcase
#18093 UPDATE: Fixed for RC3 -- New Bug discovered in Socket.Connect Method!
Posted by
Scott Green
on 16 September 2011 - 04:58 PM
in
Beta Firmware and Drivers
Michael, Dan:
You are precisely correct.The RTM was scheduled to ship on Monday of this week so we decided it wouldn't make sense to have an RC2 for a week only to replace it by the RTM version. Also, the new AnalogPort/AnalogInput class was still being changed post-RC2 and we wanted that to settle before we integrated in the SAM7X-specific code.
We're going to build an "RC3" firmware to match the .NET MF 4.2 firmware...to make sure that users don't experience any BSOD issues. This should be the first "release-quality" 4.2 firmware. From there, we'll take input from users and get things ready for an official 4.2 firmware release (and pull in the new PWM and AnalogInput objects). We may do a few RCs until the community tells us that we're good to go--but that process should go pretty quickly.
I'm excited about 4.2. In addition to VB support and GC bugfixes, there are also new features and networking enhancements. Thanks to the testing and feedback of the NETMF community, this will likely be the highest quality NETMF release to date.
Chris
Have they fixed the "unplug the USB / replug the USB" everytime you want to deploy bug?
Scott...
#17896 Unable to deploy without disconnect\reconnect USB cable
Posted by
Scott Green
on 12 September 2011 - 04:25 PM
in
Netduino Plus 2 (and Netduino Plus 1)
Hi Mike,
Are you writing large amounts of info out via Debug.Print? This can happen if the debug output stream is too busy and Visual Studio "can't get a word in edge-wise..."
Otherwise, this might be a good issue to bring up on the netmf.codeplex.com site...a recommendation for something to tweak in the desktop-side SDK.
Chris
Any update on this bug? Looks like they recommended some firmware changes on Codeplex, but thats the last thing I saw that indicated any progress had been made on resolution.
Scott...
#17683 Unable to deploy without disconnect\reconnect USB cable
Posted by
Scott Green
on 06 September 2011 - 04:31 PM
in
Netduino Plus 2 (and Netduino Plus 1)
Hi Scott,
If you erase your current app (using the Erase button in MFDeploy), do you have the same deployment issue?
Unfortunately, it seems like this is an issue specific to certain computer hardware. If you can consistently reproduce it with the latest .NET MF 4.2 release, please post a bug report on netmf.codeplex.com.
Chris
Spent all of the long weekend coding / debugging. Probably spent more time unpluging the Netduino+ than I actually did debugging and coding.
Erasing the app seems to work about 50% of the time. Again, I'm running the 4.1.1 Onewire Alpha firmware. I'd love to try the 4.2 RC but I've not seen a onewire build for that version yet. Couple of questions:
1) Not sure what everyone means by blue screen of death. Are you talking about the PC BSODing when you unplug, or the Netduino? Not sure how the netduino BSODs, but I know what a PC BSOD is, and that is not happening to me. Basically what happens is that the deployment just freezes. I have to unplug / replug the netduino 2 or more time to get it to work. Question: Is the 4.2 update causing the PC to BSOD on usb unplug during deployment? If so, I definately dont want to add more frustration to the process to have to reboot every time I change 1 line of code during a debug session.
2) Is there still additional data that is needed from users to resolve this problem? I see quite a bit of back and forth on Codeplex, but I do not see any mention of having everything that is needed to solve the issue.
Scott...
#20295 Unable to deploy without disconnect\reconnect USB cable
Posted by
Scott Green
on 07 November 2011 - 05:27 AM
in
Netduino Plus 2 (and Netduino Plus 1)
#18108 Unable to deploy without disconnect\reconnect USB cable
Posted by
Scott Green
on 17 September 2011 - 05:25 AM
in
Netduino Plus 2 (and Netduino Plus 1)
Got the same problem here with the 4.2RC1, a power cycle of the interface is required before every deploy.
So this is the latest update on this problem from the Codeplex site...
Comments
lorenzte wrote Today at 5:33 PM
Several suggestions are in the hands of SecretLabs to produce a new firmware image.
sagreen83 wrote Today at 5:02 PM
Has any progress been made fixing this bug?
Has the new firmware image been created? If so, does it fix the problem?
Scott...
#17956 Unable to deploy without disconnect\reconnect USB cable
Posted by
Scott Green
on 14 September 2011 - 01:02 AM
in
Netduino Plus 2 (and Netduino Plus 1)
#17396 Unable to deploy without disconnect\reconnect USB cable
Posted by
Scott Green
on 01 September 2011 - 04:35 PM
in
Netduino Plus 2 (and Netduino Plus 1)
#17425 Unable to deploy without disconnect\reconnect USB cable
Posted by
Scott Green
on 02 September 2011 - 04:02 AM
in
Netduino Plus 2 (and Netduino Plus 1)
#18092 Sparkfun Serial LCD Backpack
Posted by
Scott Green
on 16 September 2011 - 04:54 PM
in
General Discussion
#18100 Sparkfun Serial LCD Backpack
Posted by
Scott Green
on 17 September 2011 - 12:20 AM
in
General Discussion
#17935 Reading and storing data
Posted by
Scott Green
on 13 September 2011 - 05:24 PM
in
General Discussion
I want to read and store data from an accelerometer and I'm just wondering what the best practice is, or what the limitations are.
I have this accelerometer, and this is (hopefully soon) on it's way.
I'm just wondering what to do. I could:
I believe the first method would be best for analysis. I can run some tests and find the best algorithm for reating the data afterwards. However, can it be too much for the SD card, perhaps? Or how fast can the Netduino Plus sample data?
- Try to write data to the SD-card as fast as possible directly from the x, y and z axis.
- Average the data using one or three threads and store the average value every second or so.
- Just pull a sample every second or so and store that.
Method three is the easiest to implement, but I could be missing information I'm interessted in.
Method two is the one I'll use eventually, I believe, as it shouldn't be necessary to keep that much data.
If this had been a Windows application, I'd say just store the data and process them later. But on a little more limited hardware I'd like to know what I should do.
I am doing this exact same thing with my weatherstation project. http://forums.netdui...itor-webserver/
I use the netduino+ to sample the sensors. I have a single "stats" class that contains the values for each of the readings I am taking. So, the main program just calls a class to sample a sensor, gets that reading, and calls a stats class method to update the value for that sensor. In that method, I check to see if the value is higher or lower than my min/max values I have stored. If so, the class updates min and max, and saves a timestamp for min and max.
Every 1 second a thread wakes up and sends the values (via xml) over a socket to a server running on another PC. This server has the same stats class implemented, and it keeps averages every 1 minute, day, hour, week, month, year, and since inception. Every 1 minute a thread in the server wakes up and saves the 1 minute average to an XML log file that I can later pull into excel to do all of the trending that I want.
So, in a nutshell, isolate the main program from the statistical work via a stats class. Have the stats class summarize the data and write it where ever you want to. I chose to do this on a separate PC/Server because I was running low on memory on the netduino, and I want to write a web interface to the weatherstation. Too much work for the netduino+ IMHO.
Hope that helps,
Scott...
#18787 Power Supply Noise
Posted by
Scott Green
on 04 October 2011 - 04:31 PM
in
Netduino Plus 2 (and Netduino Plus 1)
Using a Tektronics MSO 2012 (100 MHz) scope, I observed over 1 volt of noise on the 5 volt supply, all of it negative going. I am assuming the actual noise is greater than what I observed due to the limitations of my scope's bandwidth. Also the MAX chip should ignore the noise unless it is greater than that. I observed that the noise disappears if the reset button is held down, indicating to me that the CPU and/or the Ethernet/PHY chip is creating the noise by requiring different current draws as it runs.
I am assuming the 10uF caps on the Netduino Plus's linear supplies are not large enough to handle the short term spikes in current demand. What noise levels have you seen?
Robert,
I saw the same thing with both my 5V and 3.3V lines coming from my netduino+. I switched over to powering the netduino with a wall wart, and added dedicated 5V and 3.3V regulators to my circuit supplied from the VIN line on the netduino. Smoothed the supply voltage right out.
Scott...
#16702 OneWire ALPHA
Posted by
Scott Green
on 14 August 2011 - 06:04 AM
in
Beta Firmware and Drivers
FANTASTIC! The One-Wire code in the firmware appears solid to me. I haven't seen any issues with it. Although, I really wanted to see a much simpler and object oriented way of working with 1 wire, so I wrote a wrapper class (called OneWireNetwork) out of CW2's sample. I only tested it with my DS18B20 sensors, but I have more coming soon and hopefully will add classes for them. So, what I did was create a collection class of devices that has a "Discover" method to scan the One-Wire network for devices. I hope this can be the start of a One-Wire framework that will make this the easiest One-Wire platform available. I have attached the code to this post. It is a complete replacement for CW2's OneWireTestApp project from the first post. Also, this example works with 1, 2, 3, or more devices, using parasite power or not.
By using the library, the code gets very simple:
public static void Main() { // TODO: Change pin according to the actual wiring var deviceNetwork = new OneWireNetwork(Pins.GPIO_PIN_D0); // Interrogate the devices on the network (adding them to the collection) deviceNetwork.Discover(); while (true) { // Loop through all the discovered devices foreach (var aDevice in deviceNetwork) { Debug.Print("Address: " + aDevice.Address); if (aDevice is DS18B20) Debug.Print("Temp: " + (aDevice as DS18B20).Temperature); } Thread.Sleep(20000); } }
Output:
1-Wire device present Multiple devices present 72000002DC320128 B2000002DC405128 54000002DC577D28 Address: 000002DC3201 Temp: 23.375 Address: 000002DC4051 Temp: 23.4375 Address: 000002DC577D Temp: 23.5 The program '[16] Micro Framework application: Managed' has exited with code 0 (0x0).
Things still to add:
Support for reading and writing to the device memory
Throw Events for device alerts
Robust exception handling
Throw Events for devices being added or removed
Support for a variety of One-Wire devices
Automatic instantiation of classes based on detected device family (should probably use some Reflection here)
I think CW2's firmware should get included into the next Beta. Let's get more people trying to use it...
*** Thanks again to CW2 ***
-Valkyrie-MT
Valkyrie,
I noticed that ever time you call Discover() it causes "foreach (var aDevice in gdeviceNetwork)" to add a new device to gDeviceNetwork...
May be intended, but if you put the discover in a loop, it adds a new device for every 1wire device you have on the network each time you call it. Seems like you should put a CRC check to make sure that the same device is not being added for each call...
FYI: I moved the Discover() call outside the loop, once at the top of Main() and it solved my problem..
Scott...
#16603 OneWire ALPHA
Posted by
Scott Green
on 11 August 2011 - 03:35 AM
in
Beta Firmware and Drivers
#16695 OneWire ALPHA
Posted by
Scott Green
on 13 August 2011 - 07:38 PM
in
Beta Firmware and Drivers
IMHO the problem is that your oneWire object uses pin D0 that also has alternative function of being RxD of COM1 and it tries to reserve it during its initialization, which results in exception. To resolve the issue, you can use different pin for OneWire, e.g. D2, or switch to COM2 (D2, D3) for serial communication.
CW2, That did it! Thanks!
Scott...
#16723 OneWire ALPHA
Posted by
Scott Green
on 14 August 2011 - 11:57 PM
in
Beta Firmware and Drivers
Not entirely sure I understand your question, so I'll try to answer with some observations/facts.
- You must have this native driver to directly communicate with 1-wire devices (parasitic or not) with the Netduino (alternatively, you can use components like those from Peter Anderson)
- With this firmware, I can read from a mix of DS18B20, DS18S20, DS18B20PAR sensors some connected in parasitic mode (only 2 wires - ground and 1-wire signal) and others connected with the 5VDC (non-parasitic). I currently have 5 sensors connected - 3 are not parasitic and 2 are parasitic. That works fine.
- On occassion, I will get a bad read (think 1 in 50 reads) for whatever reason (possibly because I don't have a MOSFET as recommended), but with the CRC check, you always know, so I handle them easily. And usually, it won't happen twice on the same sensor.
-Valkyrie-MT
Valkyrie,
Can you elaborate on the CRC fix you are using to deal with the bad reads? I am getting some bogus temp readings as well..
Scott...
#16689 OneWire ALPHA
Posted by
Scott Green
on 13 August 2011 - 05:49 PM
in
Beta Firmware and Drivers
#18937 OneWire ALPHA
Posted by
Scott Green
on 08 October 2011 - 07:24 PM
in
Beta Firmware and Drivers
wondering if you have gotten the CRC code (after an all channel voltage read) working with a DS2450. I know that its a 16 bit CRC, and the datasheet says that its calculated from Command Byte, Address Bytes, and Data Bytes. But I cant get a calculated 16bit CRC that matches the one that is sent back from the 2450. Heres, some test code...
var response = new byte[8];
var res2 = new byte[2];
var commandaddrdata = new byte[11]; // Array used to calculate the CRC16
var status = _core.Read(response); // Data Bytes
var stat2 = _core.Read(res2); // CRC bytes
commandaddrdata[0] = 0xAA;
commandaddrdata[1] = 0;
commandaddrdata[2] = 0;
commandaddrdata[3] = response[0];
commandaddrdata[4] = response[1];
commandaddrdata[5] = response[2];
commandaddrdata[6] = response[3];
commandaddrdata[7] = response[4];
commandaddrdata[8] = response[5];
commandaddrdata[9] = response[6];
commandaddrdata[10] = response[7];
var crc = OneWire.ComputeCRC16(response, count: 8);
var crcwithcommand = OneWire.ComputeCRC16(commandaddrdata, count: 11);
_LowByte = res2[1];
_HighByte = res2[0];
float DSCRC16 = (((UInt16)_HighByte << 8) | _LowByte);
Using this code DSCRC16 never matches crc or crcwithcommand. Have tried it with both inverted and non inverted high and low bytes on the read CRC.
Any ideas?
Thanks,
Scott...
For instance with temperature sensors, I've found that there are 2 kinds of bogus values. Ones corrupted in transmission (will fail CRC) and incomplete calculations from the sensors (which returns a default value that passes CRC). So, what I do is maintain the last sensor value in a variable and give that when requested. While at the same time, I routinely try to update the value. Below is the actual code I use for the sensor read with CRC and uninitialized value checking...
// Write command and identifier at once var matchRom = new byte[9]; Array.Copy(_rom, 0, matchRom, 1, 8); matchRom[0] = OneWire.MatchRom; _core.Reset(); _core.Write(matchRom); _core.WriteByte(DS18X20.ReadScratchpad); System.Threading.Thread.Sleep(5); // Wait Tconv (for default 12-bit resolution) var response = new byte[9]; var status = _core.Read(response); var CRCPass = OneWire.ComputeCRC(response, count: 8) == response[8]; var Initialized = OneWireExtensions.BytesToHexString(response.Range(0, 1)) != "0550"; if (status == 9 && CRCPass && Initialized) { if (this.FamilyCode == 0x28) { _lastTemp = ((short)((response[1] << 8) | response[0])) / 16F; } else if (this.FamilyCode == 0x10) { _lastTemp = (float)(((short)((response[1] << 8) | response[0])) >> 1) - 0.25F + ((float)(response[7] - response[6]) / (float)response[7]); } _lastTempTime = DateTime.Now; Debug.Print("Getting DS18X20 Temp - " + this.Address + ", " + _lastTemp.ToString()); }
Also, the .Range method is just an extension method that returns an arrange of the requested range.
-Valkyrie-MT
#19188 OneWire ALPHA
Posted by
Scott Green
on 15 October 2011 - 02:21 AM
in
Beta Firmware and Drivers
#17142 Netduino+ WeatherStation / Environment Monitor / Webserver
Posted by
Scott Green
on 27 August 2011 - 01:58 AM
in
Project Showcase
#17177 Netduino+ WeatherStation / Environment Monitor / Webserver
Posted by
Scott Green
on 28 August 2011 - 04:52 AM
in
Project Showcase
Hi Scott,
Where did you get the board mount wire holders (what I assume to be the function of the green and orange wire blocks in the last picture)? I have been looking for something that will hold some wires that are moved often a bit tighter than just plugging them into the breadboard directly.
Bought them from Sparkfun. http://www.sparkfun.com/products/10655 They also have screw terminals, but these work pretty good...
Scott...
#17175 Netduino+ WeatherStation / Environment Monitor / Webserver
Posted by
Scott Green
on 28 August 2011 - 04:18 AM
in
Project Showcase
#21264 Netduino+ WeatherStation / Environment Monitor / Webserver
Posted by
Scott Green
on 02 December 2011 - 05:59 PM
in
Project Showcase
#17897 Netduino+ WeatherStation / Environment Monitor / Webserver
Posted by
Scott Green
on 12 September 2011 - 04:37 PM
in
Project Showcase
- Netduino Forums
- → Scott Green's Content
- Privacy Policy