- Netduino Forums
- → Nobby's Content
Nobby's Content
There have been 66 items by Nobby (Search limited from 29-April 23)
#38705 Something new is brewing in the Secret Labs
Posted by Nobby on 08 November 2012 - 06:04 AM in General Discussion
#33832 Insights into DHCP issues
Posted by Nobby on 17 August 2012 - 03:27 PM in Netduino Plus 2 (and Netduino Plus 1)
Hi Nobby,
There appears to be a bugfix in lwIP to correct this type of issue. .NET MF 4.3 is getting an lwIP upgrade, so we're hoping to have a fix for this soon. [lwIP is a big complicated project and 10,000s of boards rely on it working properly...so introducing the update in beta firmware should help it get some good in-field testing.]
Chris
Thanks for the information Chris
#33808 Insights into DHCP issues
Posted by Nobby on 17 August 2012 - 04:15 AM in Netduino Plus 2 (and Netduino Plus 1)
#38703 High Resolution Quad Encoder Problem
Posted by Nobby on 08 November 2012 - 05:54 AM in General Discussion
Well, I understand the concept and I dont have a problem writing the code for say a 2.4GHz processor x86 with a 4 GBs of ram sampling time of around 1e-6 second easily, the problem I had over here was using this high resolution encoder with a netduino thats all. Just to put things in perspective, if the shaft is rotating at 3 revs/second (180 rpm which is not much )thats 1200*3 = 3600 interrupts/second. I just need help on generating an efficient enough code for the netduino to be able to handle all that along side of some computation thats all. Like I said I am just not used to micro-framework.
There's a couple of ways you can deal with your scenario. If your PID controller is for speed only then the only problem you'll face is convergence speed and possible overshoot depending on your performance specification. Even if the interrupt frequency basically matches the transport delay of the netduino hardware/framework, you just design your PID outer control loop as fast as the device can.
Position control for 3600 interrupts/sec is going to be hard. Depending on how smooth the control needs to be, you would probably have to slow the motor down. If you have to maintain a particular speed range then you'll most likely have jerky position control from lack of controller bandwidth and transport delay.
Although the netduino is capable of 100ns precision timing, most timing functions have 1ms precision. Do you have an option of a lower resolution encoder or do you need to have ridiculously fine position control?
#36842 .NET MF 4.3 beta
Posted by Nobby on 09 October 2012 - 10:30 AM in General Discussion
#39131 Alternative Purchasing Options for Netduinos
Posted by Nobby on 12 November 2012 - 06:35 AM in General Discussion
Hi Nobby,
Which region do you live in? Also, sorry to hear about your bad experience. Is it a Netduino-reseller? If so, it may be good to know for Secret Labs which reseller.
I'd prefer not to put the particulars of the issue on the forum. Is there an appropriate email contact at Secret Labs I could shoot my email off to?
#39125 Alternative Purchasing Options for Netduinos
Posted by Nobby on 12 November 2012 - 05:27 AM in General Discussion
#39225 Alternative Purchasing Options for Netduinos
Posted by Nobby on 12 November 2012 - 11:39 PM in General Discussion
I have used only Nwazet and Proto-advantage for all my stuff, both give you cheap delivery, and reasonable fast shipping.
I'm always taxed on those purchases though, since Norway have this stupid customlimit, if it cost above 200NOK (about $32) I have to pay 25% on everything including shipping.
When I bought an Arduino now, I tried to buy from the italy shop, kinda, to support buying from correct place, but they did not trust the postal system, so they required me to use an $77 UPS shipping. So, of course I bought it from Adafruit instead, which sold me the unit at proper price, and $9 in shipping
Most of my electronic stuff is coming from the two above, pluss ebay, and adafruit.
I feel your pain. My country has horrible software tariffs with the USA. Our currency is stronger than theirs but my MSDN subscription costs me nearly twice as much as a US subscriber. I don't even order DVDs, just download everything.
#38172 Getting Started with Netduino: Connecting to the Internet
Posted by Nobby on 29 October 2012 - 10:57 AM in Netduino Plus 2 (and Netduino Plus 1)
I have version 4.1 since this is what is recommended in the Download section of this site.
I tried all your suggestions and my browser still doesn't want to connect to the Netduino. I am running the example code from Chapter 8.
I really appreciate the it! Here is a screenshot of my current network settings in MFDeploy:
I noticed in your MFDeploy screenshot that your default gateway isn't in the same IP pool as the DHCP assigned IP address(192.168.5.XXX vs 192.168.1.XXX). Since you're using 24-bit networking, a lot of things are going to go south here. It also suggests that you might have some sort of configuration issue in the netduino or your router.
--Edit my bad: I saw that was your old static IP address.
#37263 Running out of memory
Posted by Nobby on 16 October 2012 - 04:31 AM in Netduino Plus 2 (and Netduino Plus 1)
#39290 Anyone try driving a relay with two output pins.
Posted by Nobby on 13 November 2012 - 09:48 PM in General Discussion
If I'm using a dual coil latching relay with voltage of 3V (with coil resistance 129 ohms), do I need to use the transistor ??
It's a bit touch & go with your situation. When they say 129 ohms, they mean total impedance. Part of it is reactive and the other is purely resistive. 129ohms at 3.3V from the CPU pin will draw up to 23mA which is borderline. If you intend on driving the relay in short bursts then it would possibly be acceptable but otherwise you wouldn't.
Once the transient behaviour dies away from switching the relay on, the effective impedance of the relay will be less and you'll exceed the maximum continuous current draw from the CPU pin and smoke the poor thing.
If it was me, I'd use a transistor.
#33205 30cm go!cable
Posted by Nobby on 07 August 2012 - 06:44 AM in Netduino Go
I don't seem to be able to find the 30cm go!cable's for sale anywhere. Does anyone have a source? I need the length for the location of the touch screen in this project.
You can make these kinds of things really easily. They require no soldering and you only need tools to do it if you want to make it easy for yourself. The Netduino Go uses standard 10-way header sockets(5x2 pin array) that have locator notches. The items you need to make cables are:
- 10-way plugs (one per end if required)
- Ribbon cable (grey or multi coloured are fine)
- Clamping tool (less than $10 and reduces chance of mistakes)
You can get all of these from electronics hobby shops and electronics parts retailers/suppliers. The 10-way plugs usually come packaged individually with three parts to them. The larger part has sharp contacts that pierce the ribbon cable wires when you clamp it. The other two pieces clip into the main piece. One is smaller than the other. The smaller one is used to clamp the ribbon into the sharp contacts. Line the ribbon up with the contacts and push down hard with the second piece(using the clamping tool makes this really easy). Once clamped, fold the ribbon back over the plug and use the final piece to brace the ribbon. It prevents tugging from ripping the ribbon out of the plug.
The ribbon cable can be bought in lengths you require. If you can't get ribbon with 10 wires in it, just buy anything larger than that. I personally have a massive roll of 16-way that I use for everything and strip off what I don't need for a particular cable. Sometimes you can buy bundles from electronics hobby shops which have breadboard wires and ribbon cable in them with other junk if they don't sell ribbon cable.
Not sure what country you live in but I've never seen these cables pre-made purely because they're not used in consumer electronics for external purposes. I have read that packs of 10-way cables for the Netduino will be sold soon within the USA for people who aren't hardware savey. Not sure what the status on that is.
#32186 I2C communication with GainSpan GS1011
Posted by Nobby on 18 July 2012 - 11:18 AM in Netduino Plus 2 (and Netduino Plus 1)
#38212 How to check if ethernet is connected?
Posted by Nobby on 30 October 2012 - 12:45 AM in Netduino Plus 2 (and Netduino Plus 1)
#32848 ADC
Posted by Nobby on 28 July 2012 - 01:33 PM in Netduino Plus 2 (and Netduino Plus 1)
Thank you Mario for your response.
I know that the framework slows things down..But most of teh time the developper is the problem!
But I know that on a PC, the differences is sometimes hard to see..
The conversion time of an ADC can be less than 5 Microseconds..
A simple loop with simple calculation run very fast.
It is the call to the ADC which goes wrong.
Usually, it is possible to start conversion, than to read the result later.
With NetDuino, it seems that we have to start and wait conversion..
Even though, response time is very long...
What I want to to is to store data from 1khz ->10khz signal into memory, and dump it from a PC.
It works fine for 100hz signal..
I will work on it...
If you configure the ADC to operate in free-running mode, the contents of the ADC register is constantly changing for you at the maximum rate the ADC will operate at. This kinda eliminates conversion times from a hardware interrupt. There are two probelms with a free-running ADC.
If you strobe multiple pins you run into parallel operation errors. I haven't checked the SAM7 architecture but most AVRs only have 1 ADC but have 5+ pins you can strobe off. When you change the ADC strobing register to select another pin, it might be impossible to determine which pin the ADC data register contents belongs to if you read it immediately or shortly after. Some AVRs don't allow free-running with strobing.
The other issue you have is when you read a sample from the ADC register in free-running mode, you don't know how "old" the data is. When you take two readings, there will always be a degree of skew in your measurement windows which increases with a slower ADC sampling rate.
Those two issues aside, it's also a tall-order to measure a time interval less than 1ms accurately.
#32747 Circuit example for 4-20mA measurement
Posted by Nobby on 27 July 2012 - 03:28 AM in Netduino Plus 2 (and Netduino Plus 1)
Hi Guys,
Separately, do you have any sample circuit to connect to N+ for measuring 4-20mA Analog input?
Together with sample code will be great. Currently I am using VB.net to handle the 12V pulse input through opto-coupler circuit.
Thanks in advance.
I don't think you can measure current with a microcontroller. You need to transduce the current to a voltage.
The most accurate method is getting a transducer which uses electromagnetic coupling. It's also the most expensive method.
The easiest method is to use a really small series resistance (1-5 ohms, whatever you can get your hands on) with the circuit you are measuring current. Measure the voltage across the resistance and divide that by the series resistance in your netduino code. The result has errors obviously. Adding resistance to the circuit changes the current. You might also get non-negligable current flow into the analog pin even if it has a high impedence characteristic during analog sampling.
The other consideration you need to be aware of is that 4-20mA is a rather small current to transduce. Mostly because ADC(Analog to Digital Conversion) usually has a precision relative to the operating voltage of the microcontroller(AVR/Netduino) and the value of AREF(usually set to zero volts or Vcc/2). A current that small will produce a voltage so small it will appear as zero after ADC. You'll need to amplify the transduced current signal significantly, especially if you are working in a narrow measurement range (4-20mA).
You can make a simple voltage amplifier with two resistors and an op-amp package.
#32847 Circuit example for 4-20mA measurement
Posted by Nobby on 28 July 2012 - 01:21 PM in Netduino Plus 2 (and Netduino Plus 1)
Hello Alex,
Sound a typical field instrumentation problem.
Use a 250ohms in parallel to 4-20mA signal. Remember V=IR .... V=(4/1000)(250) = 1V...do similar
operation for 20mA and you get 5VDC...right in the acceptable voltage range of the Analog inputs...
Hope helps.
You can't measure the current of a circuit using a parallel impedence, that's only appropriate for voltage measurements(scale conversion). Parallel impedence splits the current through branched paths and it also alters the characteristics of the circuit in a large way(unless the impedence is essentially infinite, 250ohms is very low).
The current transducer circuit has to run in series and have a negligable impedence.
#39296 Connecting a motor to the netduino
Posted by Nobby on 13 November 2012 - 10:19 PM in General Discussion
You haven't specified what your H-Bridge is and how it's been put together etc. They're simple systems to understand. You need to connect at least three different kinds of connections:
- DC Bus link voltage. This is the power supply you provide the H-Bridge. It can be bi-polar or uni-polar but it depends on if your H-bridge will allow you to connect a 'center-tap' for setting the ground as a mid-point.
- CMOS/IGBT gate inputs. You connect your PWM outputs to these. There are four of them but they are in pairs so you only need two PWMs to drive it. One switch is always off when the other is on for each pair(side note on this)
- H-Bridge output goes to the motor. You will be able to drive a DC or an AC motor with an H-bridge.
There may be some other component considerations depending on the gear you've bought.
Controlling the motor can be as easy or difficult as you want and it's a massive field for you to explore. To start with, you will most likely be able to get a library or use .Net classes which will operate the PWMs for you. Because you have an H-Bridge you have two options:
- Use one PWM on half of the H-Bridge as a starting point. It turns your H-Bridge into a single phase-leg modulator which means you can't drive an AC motor
- Use two PWMs on the full H-bridge which will allow you to drive an AC motor as well as DC
Above is your starting point but it has no feedback control loop. Without feedback from the motor, you won't be able to know how fast it is actually spinning for a given input signal. If it's important for you to have precise control of the motor speed, you need software in your project which will measure the motor speed and figure out the difference in desired speed and actual speed the adjust your modulation depth to drive the H-bridge harder or less. Some motors can tell you their position as well so you can precisely control the position of the motor as well as speed.
Having said all this, if you're just a hobbyist and want to see the motor spin, you don't need a feedback control system or understand much about modulation theory. If you told us more about your goals then we can be very specific about helping you to setup the right system.
--edit: oops forgot the side note. Depending on how your H-bridge has been designed, you have to build a "dead-zone" into the PWM signal. If there's free-wheeling diodes and/or your H-bridge uses IGBTs, there's a discharge transient when the device attempts to switch off. If you toggle the other switch on before its complimentry switch has fully turned off, you create a short on your power supply every time the PWM switches on/off. It will damage your supply and possibly much more.
#31953 Timing Accuracy Issues
Posted by Nobby on 13 July 2012 - 05:01 AM in General Discussion
Hi Nobby,
Is the elapsed time from timers/Stopwatch not matching the increase in DateTime.Now?
Losing 10 seconds in 15 minutes is a lot (~1.1%).
Can you post a quick code snippet showing how you're calculating and writing out the time? We should be able to run it on our Netduinos to reproduce...
Finally...just curious: if you reflash the mainboard with Netduino firmware (instead of Netduino Plus) do you get the same results?
Chris
Hey Chris,
Due to the nature of my project, I can't share code but I have created a new project which is dedicated to the task of timing using Ticks.
The project has three threads. The main program thread, aka Main(), sits in a for(; loop with a Thread.Sleep(500) call. It does this after it initialises a class that manages the time measurements.
The second thread is fed a time object and reduces its time until it reaches zero or less. The thread is executed with default priority through a lambda expression.
private static void timerFunc(Clock clock) { if (clock == null) return; long startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks; long endTicks, delta; while (clock.time > 0) { endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks; delta = (endTicks - startTicks) / m_tick; //where m_tick is System.TimeStamp.TicksPerMillisecond clock.time -= delta; startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks; Thread.Sleep(50); } }
The third thread is one that runs in the clock class. It sleeps for 100ms and then uses COM1 to write, in ASCII text, the value of the time of the format "mm:ss.f".
I just started a 15min test against my sports wristwatch and PC application. 10mins into the test, clock.time is eight seconds higher than the timer on my watch.
I haven't tried flashing my Netduino Plus with the Netduino firmware. I have a regular Netduino to use and a handfull of Netduino Plus devices I can downgrade if necessary.
Currently, I'm stuck with the newest firmware for my commercial project. Purely because of the Socket runtime code footprint providing a much needed 10K.
Thanks for having a look at this
#31955 Timing Accuracy Issues
Posted by Nobby on 13 July 2012 - 05:19 AM in General Discussion
#31973 Timing Accuracy Issues
Posted by Nobby on 13 July 2012 - 12:41 PM in General Discussion
long startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks, endTicks=0, delta=0; int sleepTime = 50, choice=1; clock.start = startTicks; for(;;) { if (choice == 0) { Thread.Sleep(sleepTime); //Sleep to regulate timing intervals. 50ms here. endTicks = Utility.GetMachineTime().Ticks; //Get the current Netduino time delta = endTicks - startTicks; //Calculate the time difference startTicks = endTicks; //Assume significant overhead from the previous line of code clock.time += delta; //Increment instance member time value } else if (choice == 1) { Thread.Sleep(sleepTime); endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks; delta = endTicks - startTicks; startTicks = Utility.GetMachineTime().Ticks; //Assume no overhead from the previous line of code and this line as well clock.time += delta; } else if (choice == 2) { //Choices 2 & 3 just involve a different order of operations but have the same logic as 1 & 2 endTicks = Utility.GetMachineTime().Ticks; delta = endTicks - startTicks; startTicks = endTicks; //Assume overhead from the previous line of code clock.time += delta; Thread.Sleep(sleepTime); } else if (choice == 3) { endTicks = Utility.GetMachineTime().Ticks; delta = endTicks - startTicks; startTicks = Utility.GetMachineTime().Ticks; //Assume no overhead from last and this line of code clock.time += delta; Thread.Sleep(sleepTime); } }
I performed some optimisations on my original timing code which was not optimised at the time. There was still drift. The results were fairly conclussive though. Choices 0 & 2 provided identical and ideal results. There was no slip between clock.time, the Netduino time and the PC time.
Choices 1 & 3 resulted in the slip of 100ms every 30seconds. The only difference in code was using startTicks = Utility.GetMachineTime().Ticks vs startTicks = endTicks. The previous line of code, delta = endTick - startTicks and the alternative code in choices 1 & 3 were resulting in what appears to be significant overhead. Based on the results and a loop interval of roughly 50ms, it works out to be roughly 166us of slip per itteration.
Not being a huge fanatic of investigating the inner workings of the micro framework, I'm just going to accept that I can't be lazy in design with respect to these things. Failing longer duration tests for choices 0 & 2, There's no evidence of any chronic issue with timing accuracy.
#32011 Timing Accuracy Issues
Posted by Nobby on 14 July 2012 - 08:44 AM in General Discussion
#32581 Passing Servo's to another thread.
Posted by Nobby on 24 July 2012 - 12:03 AM in Netduino Plus 2 (and Netduino Plus 1)
#31951 Timing Accuracy Issues
Posted by Nobby on 13 July 2012 - 03:54 AM in General Discussion
#31958 Timing Accuracy Issues
Posted by Nobby on 13 July 2012 - 05:31 AM in General Discussion
Hey Nobby,
Thank you for the additional information. Let's boil it down a bit more, to isolate any potential code or threading issues...
Can you please try creating an app which simply does the following:
- Create and open an instance of the SerialPort class
- In a loop: write the current time to the serial port and then sleep 500ms
And then share that code along with your results? If that basic case is losing 1+ seconds per minute...or if it's not...then we'll have a good basis for diagnostics.
Thank you, Nobby.
Chris
Getting onto that right now.
- Netduino Forums
- → Nobby's Content
- Privacy Policy