using pwm pins 9 - 11 and the transceiver at the same time?

[thor]

Hi all.

I am having a good time with the monteinos and would like to control a bidirectional dcmotor and two servo motors hooked up to a monteino  remotely at six different locations, as well as reading data from a single sensor at four additional monteinos.

I have now control over the motors wirelessly and have a single link for the sensor data up and running as well. But have a couple of questions:

Since pwm pin 9 - 11 is shared with the led light and transceiver I have not been able to make them work reliably while using the radio. I am now using 3, 5, 6 and 9, where  the remaining problem is that since pin 9 is shared with the led the servo connected there goes haywire when programming the chip.
Questions:
1. Is it possible to use pwm 10 and 11 while also using the radio?
2. Is it possible to disable the led and free up pin 9 to work only as a pwm pin, (not being affected by programming the chip)?

I know the following has been mentioned before but I also have a question regarding collision of data:

3. The sensor network consists of 4 different sensors connected to a monteino each. I would like them to send the sensor data as quite often, (allthough dropped packages is not a problem as long as the data mostly gets through.) if possible as often as every 50 - 100 ms. 
There will be a computer receiving the data so I could poll each monteino by asking for the data or have them push out the data automatically.
Which is the better approach?

4. The monteinos running the motors do not need to communicate with the sensor network, is it best to have them on the same network as the sensors, or set up a new network for them?

Thank you for any and all tips!

All the best
Thor

[Felix]

thor, welcome!

You cannot share any pins already used with anything else, unless there is no SPI device (radio, FLASH_MEM).
For more PWM use a Moteino MEGA, check the available pins on that: http://lowpowerlab.com/moteino/#pinout

For the onboard LED you can cut the trace to the LED or from the LED to GND (this allows you to hook it back up with a tiny hookup wire if you later want to), and this allows freeing up the D9 pin (or D15 on MEGA) for other uses. Maybe I will put a jumper in future revisions to make this easier...

Sending a packet over radio waves takes time. The longer the packet, the longer it takes (in terms of milliseconds). Although the library does a best effort to listen-before send to avoid collisions, the more packets fly around the more chance for collision. So with a lot of nodes and a lot of data it's a hard problem to divide the time in very tightly controlled sections to maximize throughput and also avoid lots of collisions. The default bitrate of 55kbps will give you a very decent throughput. I believe it would be better for your controller to ask the nodes for data in a multi node network where all the nodes need to send data as quickly as possible, the reason being that the controller is now the bottleneck and cannot receive more than 1 packet at 1 time anyway.

If you have separate networks that don't talk to each other I would keep them on separate frequencies that are at least 1mhz apart from the default central frequency of the band of your radio. The default preset freq out of box is 915mhz (or 433mhz). You can set another frequency for instance 910mhz (910 million herts) like this:

Code Select Expand

radio.setFrequency(910000000);

[TomWS]

<snip>
Questions:
1. Is it possible to use pwm 10 and 11 while also using the radio?

As Felix mentioned, no these have to be dedicated to the radio and SPI respectively.

2. Is it possible to disable the led and free up pin 9 to work only as a pwm pin, (not being affected by programming the chip)?

If you don't care that the LED flashes while using the motor, but simply don't want it driving your motors crazy while downloading, there is a way to use the PWM function on pin 9 but disable it when not controlling motors.  To do this you would need either a transistor and one resistor or a single AND gate.

If either of these approaches are interesting then just reply and I'll throw together a diagram to show how.

Felix also mentioned the Mega, which is a good choice for many reasons (much more data memory and, of course, more PWM pins, for example)  if you have room for it.

Tom

[TomWS]

<snip>
3. The sensor network consists of 4 different sensors connected to a monteino each. I would like them to send the sensor data as quite often, (allthough dropped packages is not a problem as long as the data mostly gets through.) if possible as often as every 50 - 100 ms. 
There will be a computer receiving the data so I could poll each monteino by asking for the data or have them push out the data automatically.
Which is the better approach?
<snip>

Sorry, I forgot to answer this one... Again, Felix makes a good point about data rate and his suggestion to shift the frequency so that the sensor network is completely dedicated to the sensors is a very good one.  However, even with that, it would be difficult to achieve reliable comm link where you have 4 sensors each sending data every 100mS (I don't think 50mS is possible unless the link distance is short and the data rate increased over standard Moteino rate). 

To achieve this, the most reliable way probably requires that ALL nodes 'know' where all other nodes are with respect to their transmit timing.  In this case I would try to use a BROADCAST protocol so your controller can BROADCAST "I want to start a sequence with Node 0", then Node 0 sends it's packet while all others wait.  Node 1 sees Node 0's packet and then knows it can send it's packet, etc until all packets are sent.  There won't be any margin for retries so you might have to include a timing escape in case Node 2 never sees an earlier packet, for example...

Tom

[thor]

Hi Felix and Tom, thank you so much for your replies.

Excellent about the shifting of frequencies! Thats a really nice feature I will set up to separate networks each communicating to its own gateway (ftdi into computer.)

When I was testing this with a single sensor link I did pump out the data at 50 ms (its just a single number) with excellent range through several walls and so on. Allthough that was a while ago (couple of days:-)) so I am not sure if it was dropping packets or not. The data that came in was very good though.

That being said its not going to be much of a problem to set up a polling system that requests the data and waits for a reply (w timeout) before asking the next node so that is what I will do. It will be interesting to see how fast it can go. I might test both approaches though just to see how it behaves:-)

Tom, when you say broadcast mode, that as I understand it means sending to node ID=255? And do the receivers then need to be in promiscuous mode to know when the other nodes answers the poll?
That approach seems a little more involved for the early stage of monteino experience I am at, but I will certainly look into it when I see what kind of timing I get with the other system.

No problem with the little light flashing when the servo is running, its more that the servo will be driving a structure that is a little fragile, sudden movements could damage it..
So if you are willing to upload a simple diagram, that would be fantastic, I was thinking about a hardware switch myself:-) but using a transistor seems like a more elegant solution. (And may take away the danger of forgetting to flick the switch before programming. )
I will not be programming the cip over the air I will always plug it in.

The monteino is somewhat cheaper than the mega, so that is an argument for me since I in the longer run would like to build quite a few units.

The project is multiple dancing wooden arm at times controlled by input from muscle sensors by the way:-)

Thank you so much for your help!

Thor

[TomWS]

Tom, when you say broadcast mode, that as I understand it means sending to node ID=255? And do the receivers then need to be in promiscuous mode to know when the other nodes answers the poll?
That approach seems a little more involved for the early stage of monteino experience I am at, but I will certainly look into it when I see what kind of timing I get with the other system.

Yes, to the question of address, from a code point of view each node and gateway would use:

Code Select Expand

  radio.send(RF69_BROADCAST_ADDR, ...);

And each node would listen in the same way as it would if the message had been sent directly to that node and each node still has a unique node ID.  The only difference is that radio.TARGET would contain RF69_BROADCAST_ADDR instead of the node's ID.  The RFM69 library treats these as the same in the receive logic.  The other difference is that you would never request an ACK on a BROADCAST (who should reply?) and you would never check to see that an ACK was requested on a BROADCAST.  The rest of the receive code is identical.

I suppose promiscuous mode could be used for this case (I generally only use this in a snooper) where each node, being in promiscuous mode, would receive every packet and know if the packet was sent by the Node's ID-1 (in which case the Node could send its packet next) and the Gateway Node has the lowest node number so it could send practically anything and the NodeID == GatewayID+1 would know to send immediately.   As I think about it, that may be the lowest overhead of all!

No problem with the little light flashing when the servo is running, its more that the servo will be driving a structure that is a little fragile, sudden movements could damage it..
So if you are willing to upload a simple diagram, that would be fantastic, I was thinking about a hardware switch myself:-) but using a transistor seems like a more elegant solution. (And may take away the danger of forgetting to flick the switch before programming. )
I will not be programming the cip over the air I will always plug it in.

The monteino is somewhat cheaper than the mega, so that is an argument for me since I in the longer run would like to build quite a few units.

Ok, I'll have something for you by tomorrow.  The transistor solution is easiest, but WHICH transistor depends on what your soldering capabilities are.  The best transistors to use are low threshold MOSFETs but these mostly come in SOT-23 packages.  These can be hand soldered, but 'breadboarding' generally requires a breakout board.  I'll include a couple of options.

The project is multiple dancing wooden arm at times controlled by input from muscle sensors by the way:-)

Thank you so much for your help!

Thor

Hey, that's sounds  fascinating!  I'd like to see that!

Tom

[TomWS]

Attached is a schematic showing two different ways to use a transistor to enable PWM from Pin 9 without causing unwanted signals to your motor during program upload.  In both cases the circuits rely on using a digital Pin (D7 in this case but it could be any digital pin) to 'enable' the PWM signal to the motor. 

On program load (after the Moteino is reset) the digital pin will be configured as an input and won't provide any voltage to the MOTORx-PWM signals.

In setup() you would:

Code Select Expand

  digitalWrite(7,LOW);  // make sure 'enable' is LOW first
  pinMode(7,OUTPUT); // make enable an output

Then, when you are ready to use pin 9 as a PWM signal, you would:

Code Select Expand

  digitalWrite(7,HIGH);
  analogWrite(9, 256-myPWMvalue);  // this effectively creates a 'normal' PWM signal since the output transistors will invert the signal on pin 9.

Which circuit you choose is pretty arbitrary.   The NPN transistor will be easier to manually wire, the MOSFET uses one less resistor and draws slightly less current.  Note that if you need this PWM signal to be in phase with the other PWM signals then you would need an AND gate and some extra code to ensure the AVR counters are matched.

Tom