Arbiter - Viewing Profile: Posts - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content

  2. → Viewing Profile: Posts: Arbiter

The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Arbiter

Member Since 09 Jan 2012
Offline Last Active Sep 09 2013 06:00 AM
-----

Posts I've Made

In Topic: netduino plus 2 compatible gps/gsm module

09 September 2013 - 06:01 AM

You'll have to write your own drivers.

 

Most carriers charge outrageously for GSM, making it a very expensive way to do tracking comms. I had a look at the SIM908 chipset and it doesn't appear to support anything newer than GSM. Nor does it surface a connector for an external GPS antenna, which means you will need an IP66 enclosure because you'll have to roof mount it to get a lock in weak signal conditions.

 

To improve reliability and mitigate operational costs I recommend a store and forward architecture, for which this shield is not an ideal choice.

 

So far as I can determine, the SIM908 does not support altitude. If altitude matters to you then you need a shield that supports a uBlox 5, 6 or later such as this http://www.dfrobot.c...81#.Ui1kDdV-8dU.

 

I haven't personally used that one but I do intend to test one at some point.


In Topic: Help with PWM

09 September 2013 - 04:21 AM

Frequency is Hz. Your value of 10000 means that a pulse will be generated every tenth of a millisecond. Duration is in microseconds. Your duration of zero will produce either nothing at all or a brief twitch because the rising and falling edges aren't truly vertical.

 

To produce a 50% duty cycle you need the duration to be half the interval. Specifying a frequency of 100Hz ie an interval of 10ms, you will need a period of 5000µs (5ms) to get 50%, so values of 1000, 2000, 3000, 4000, 5000 will produce duty cycles of 10%, 20%, 30%, 40% and 50%.

static PWM ledR = new PWM(PWMChannels.PWM_PIN_D11, 100, 4000, false); //40%

You could also run a short interval (higher frequency) with narrower pulses.

static PWM ledR = new PWM(PWMChannels.PWM_PIN_D11, 10000, 30, false); //30%

This will produce a smoother steadier glow.

 

I haven't played with an RGB LED but I imagine that it's essentially three LEDs in one package, probably with three signal leads one for each of R, G and B, and a shared earth lead. Presumably you will use three separate PWMs to control the intensities of R G B to mix your own colour; if you skip the PWMs and pull all three control leads high I imagine you would get bright white.

 

There is another constructor that allows duration to be specified in nanoseconds. Be aware that the inductance of thick conductors may become significant at higher frequencies. You won't notice in the kilohertz range that you seem to want to use.

 

Servomotors expect a frequency of 50Hz (an interval of 20ms) and the pulse width is what controls the servomotor. A pulse width of 1000µs turns the servo as far counter-clockwise as it will turn, and a pulse width of 2000µs turns it as far clockwise as it will go. A pulse width of 1500µs turns the servo to the centre of its range which is generally regarded as the zero position.

static PWM servo = new PWM(PWMChannels.PWM_PIN_D11, 50, 1500, false); //centre position

Other frequencies and durations may work because the servo is actually controlled by the voltage produced in an RLC circuit inside it which is a function of the duty cycle. But the specification calls for the interval and range of duration I have specified above, and there are quite enough surprises in the world without going looking for them. On the other hand if you don't mind damaging a few servos, out of range values can produce some quite fascinating behaviour.


In Topic: SD extension & SIM extension

09 September 2013 - 02:33 AM

Probably there is no simple answer to this, but I'll ask anyway.

 

Why is it so hard to support SDHC?

 

KodeDaemon and others have been looking at this problem for years now. I imagine there is something horrible about SDHC or they would have shipped something a long time ago.


In Topic: Quad.Net Quadrocopter for .NETMF

23 January 2013 - 01:31 PM

I cannot help but wonder whether required thrust can be expressed as a function of inputs using an FPGA. Possibly one per motor. I would expect inputs to include 

  • required vector
  • accelerometers
  • gyros
  • velocity
  • current vector
  • last-interation thrust values for all engines

and of course it would be necessary to clip the magnitude of the requested vector to what is actually possible with available thrust.

 

Using an FPGA would make it possible to make very frequent microadjustments; the Netduino would fulfil a role more like an autopilot. Such an arrangement would be excellent for building a drone.


In Topic: Netduino Plus, DIS(Direct Ignition System) and transistor help

07 January 2013 - 02:14 PM

While it's great that you learnt to DIY, you can save yourself a lot of messing about with one of these relay shields.

 

http://littlebirdele...ts/relay-shield


  1. Netduino Forums
  2. → Viewing Profile: Posts: Arbiter
  3. Privacy Policy
home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.