PhantomX using a Teensy 3.1

[KurtEck]

Zenta: sounds good. Yep it is pretty cheap from Seeed, which is why I may order a batch of the ones with Arduino Headers. Not sure how I will use these, but maybe on Rover using something other than XBee...

General electrical question for those with more experience than I do. (Which is probably most of you )

On the current one with Arduino Headers,

I am trying to give several different options for power, with two sets of inputs, that can all be hooked to each other, or one is setup to only go to the AX connections, but can be Jumpered to VS, the 2nd one goes to 5v/3v regulators and also can be jumpered to VS.

But in addition, the Teensy has a soldered in jumper on the bottom that can be removed that jumpers VUSB to it's VL. So I have added two sets of jumpers up there that allow me to jumper VL back to VUSB and/or VL to +5v from. But for the most part I would proabably always not undo their solder joint, so I put in a soldered in jumper
But doing so DipTrace likes to complain in verification about pads to close, short circuit...

So couple of questions: First off is this overkill? Since I probably won't over need myself.

Do you use these types of solder jumpers (this one came from Sparkfun library), or do you do something like install a 0 ohm resistor as to make everything happy...

Thanks

[JonHylands]

It really depends on what rules you have defined in DipTrace. Seeedstudio specifies a 6 mil clearance between pads and traces (http://www.seeedstudio.com/service/i...n#Manufacturer - Minimum trace/vias/pads space). OSH Park has the same clearance rule.

So it might be the corner of that pad coming close to the trace that is below and to the right, on the diagonal. However, if I was doing your board, I would definitely put in an actual 0603 resistor, and use a 0-ohm to jump it if required. I never power my robot boards from usb - it introduces too many issues with power coming from both the batteries and usb, so on my Teensy cutting that trace was the first thing I did. Browse: ALDI Circular and Meijer Sale Ad on Weekly Circulars.

- Jon

[tician]

Not sure how diptrace works it, but in eagle (still using eagle-5.11, so may have changed in v6.0+): cuttable traces between pads in user-generated jumper designs tend to require approval of the overlap error(s), but correctly designed parts should never cause any clearance errors in the design check. The FSR-trace parts that I created for the target panels (and other boards) have two small SMD or PTH pads and a lot of manually drawn traces, but the manual traces in part designs never actually get an accessible signal name so they always require overlap approval where they touch the pads (disconnected traces in parts get different inaccessible names, so will still cause clearance errors if too close but not connected).

[KurtEck]

Thanks guys. Yes I can remove most of the errors in the verification, by changing my rules. However these pads are about 4mil from each other, so I don't want to relax it that much. Also if I do a Net connectivity test, it shows that the two networks are shorted. I have looked up on their forums, and sounds like this has been discussed before... For me, I will probably punt and remove it. I already have it setup for a two pin Jumper which I can always put on. But to give me that option, may simply replace with a 0603 or a 0402 0Ohm just in case I change my mind.

Thanks again

Kurt

P.S. - Did some more playing with the Phoenix Phantom on Teensy code base yesterday and put it on the ground and it was walking about the same as the Nuke version on either platform.

[KurtEck]

I punted - and converted the solder jumper to an 0402 resister on top. I prefer to keep larger clearances on design... Also if I decide to populate it not much of a cost. $.10 for 1 and $.14 for 10... Again not sure what I will use this board for, but since I spent enough time on it, I put in an order to Seeed. I put a zip file up on Lynxmotion forum (http://www.lynxmotion.net/viewtopic....p=89860#p89860), that includes the stuff for either Seed or OSH Park, also has design documents...

Now back to building Shed/Chicken Coop and working on the PhantomX. (And seeing if there are any other controller boards out there I have missed )

[TXBDan]

Cool. A 0ohm resistor footprint is def the way to go. You can always jumper it with bus wire. I would have gone with a 0603 to make that a little easier.

[Zenta]

Digikey was really fast. Got all the parts for the boards today! I liked the big power terminals. Looking forward to the rest.

[Zenta]

A second thought about the terminal block. I believe I'm one part short to make the terminal block fit the board. http://www.digikey.no/product-search...ords=ED2655-ND There should probably be a socket with pins to solder on the board first. Looking more closely to the specs on digikey, you need a mating part like these: http://www.on-shore.com/sites/defaul...STOPXX0000.pdf

[KurtEck]

Oops - Thought I updated the Excel document: I ran into that as well. Two choice, get the matching one as you mentioned (which I did order a couple of, or the one that I used on the board: http://www.digikey.com/product-searc...ds=277-1667-nd

Kurt

[KurtEck]

Ran into something yesterday that I was pulling hairs out to try to figure out. I put in the automatic reconfigure the XBee code in my Teensy version for the Phoenix, and it was failing. When it failed to properly talk at first 38400 with a short time out, then the standard 1 second timeout and then at 9600 baud, on the Commander version, I just looped forever with a fast blink of the LED. This was happening in the Phantom Phoenix code on the Teensy. I removed the forever loop and then it would come up. Note: this only happens on powerup, works fine if there is a reboot.

So I hooked it up to Logic Analyzer with a real simple program:

#define XBeeSerial Serial2
void setup() {
   pinMode(2, OUTPUT);
   digitalWrite(2, LOW);
   delay(250);  // give time to settle
   XBeeSerial.begin(38400);
   digitalWrite(2, HIGH);
 }

 void loop() {   
  if (XBeeSerial.read() != -1)     
    digitalWrite(2, !digitalRead(2)); 
}

had the Commander on and started the logic Analyzer and powered up the board and found:

Sure enough there was over a 10 second wait at startup before it would see the packets coming in. There was some garbage at the start of the session as well. Turns out it was not garbage but output at 9600 baud: the TX line had: 0xff 0xff 0xff,
The RX line (simultaneous to TX) showed OK<CR>. It appears that the system entered Command mode at 9600. This is probably the XBee mechanism that for example when you think you have a bricked on, you can tell it to read/or write without the XBee in the socket and then when it errors, you insert it...

I did a quick change to the test program and, brought the code up at 9600 first, output ATCN<cr> and then entered 38400 and it appears to cut that off. So I am going to change my default code that at init time it will try to detect data coming in at 9600 and if so output the ATCN command and get back out...

But it also made me wonder if I have been running into this in the past as there are times when it appears like the PhantomX takes a long time to respond to the Arbotix...

Kurt