You need to be a member of diydrones to add comments!
This reply was deleted.
Activity
RT @donkey_car: Human-scale Donkey Car! Hope this makes it to a @diyrobocars race https://www.youtube.com/watch?v=ZMaf031U8jg
RT @GrantEMoe: I won my first @diyrobocars @donkey_car virtual race! Many thanks to @chr1sa @EllerbachMaxime @tawnkramer and everyone who m…
RT @gclue_akira: JetRacerで自動走行したコースを、InstantNeRFで再構築。データセットは別々に収集 #jetracer #instantNeRT https://t.co/T8zjg3MFyO
RT @SmallpixelCar: SPC 3.0 Now the motor also works. This car is doable. I just need to design a deck to mount my compute and sensors. http…
RT @SmallpixelCar: High speed at @diyrobocars thanks @EdwardM26321707 for sharing the video https://t.co/o4317Y2U1S
RT @SmallpixelCar: Today at @RAMS_RC_Club for @diyrobocars. Used @emlid RTK GPS and @adafruit @BoschGlobal IMU. Lap time 28s https://t.co/R…
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
Our next Virtual Race will be on June 4th:
https://www.meetup.com/DIYRobocars/events/285787423?utm_medium=referral&utm_campaign=share-btn_savedevents_share_modal&utm_source=link
RT @SmallpixelCar: Noticed my car zigzagged in last run. It turned out to be the grass stuck in the wheel and made the odometry less accura…
Replies
I wrote a small program which just basically simulates sending servo position update packets via the XBee 868 to a receiver unit. What I tried out now is to simply reset the modem and wait for a small moment before retransmitting data, between every full update packet.
Of course this is not optimal, it should not reset so often etc, but I did it like this to test the theory with minimal work.
And it works like clockwork, but it does have a delay between payloads and thus is slower than it would be without the reset and delay. So I will work on an optimal transmit loop count between resets based on my payload, and anyone else could do the same.
To reset the modem connect a cable between the RST pin on the adafruit module and one of the digital pins on the Arduino/ArduPilot.
Then just simply add this:
in void setup()
pinMode(resetPin,OUTPUT);
digitalWrite(resetPin,HIGH);//set the RST pin high, low will reset the module
And then in the loop code with apropriate counter (you can find this out easily if you transmit a same size payload every time, otherwise make it low enough to be safe - otherwise use response ACK packet timeout to activate)
delay(TXdelay);//wait for data to transmit
digitalWrite(resetPin,LOW);//press reset
delay(RSTactiveDelay);//spec minimum is 100us to register
digitalWrite(resetPin,HIGH);//release
delay(RSTrecoverDelay);//wait for XBee to initialize
Of course you'll need to tune your variables for your particular application, and define them.
Like
servo actions, motor, video streaming, Chat window. or file transfer ...
let me know.. Thanks, Mogly
1mw loopback test, 4800bps, standard X-CTU test string, 3365packets went through until it hit a wall. Resetting only one or the other XBee did not suffice, both had to be reset.
100mw loopback test, otherwise same thing with settings, tried with both firmware 1025 and 1027 and both stop at exacly 3465packets, same issue there, resetting one does not solve the issue, resetting both does....
I am testing 300mw now, and there seems to be no difference at all here, same 100% link until it drops...
Has anyone else encountered these same (exact??!) numbers?
I am thinking this should either way not be hard to overcome seeing that the unit works again after reset without cooling it or anything, so I think I'll stick some code in the arduino to do this for me every so often...
Anyways surface temp on the units stays within ~45 degrees give or take a few so the heat should not be the issue.
P.S. The relevant code is in bold, all the rest of the code also does work once the RSSI stuff is commented out.
Thanks,
Zach Long
striker0010@gmail.com
#include
#include "Message.h"
int greenLedPin = 11;
int redLedPin =10;
long connectionSpeed = 9600;
Message incomming;
Message outgoing;
long R_status=0;
long G_status = 0;
int tmp;
int RSSI =0;
/*
* This is the callback function that is called whenever the data is updated.
*/
void dataUpdate(SerializationData *data)
{
RSSI = pulseIn(9,HIGH);
outgoing.setTitle("signal_r");
outgoing.setData(RSSI);
SimpleSerialization.write(&outgoing);
delay(10);
if(strcmp(((Message *)data)->getTitle(),"red_Set") ==0)
{
if (((Message *)data)->getData() == 1)
{
digitalWrite(redLedPin, HIGH);
R_status = 1;
}
else
{
digitalWrite(redLedPin, LOW);
R_status = 0;
}
// outgoing.setTitle("red_Status");
// outgoing.setData(R_status);
}
else if (strcmp(((Message *)data)->getTitle(),"green_Set") ==0)
{
if (((Message *)data)->getData() == 1)
{
digitalWrite(greenLedPin, HIGH);
G_status = 1;
}
else
{
digitalWrite(greenLedPin, LOW);
G_status = 0;
}
}
}
void setup()
{
Serial.begin(9600);
digitalWrite(13,HIGH);
Serial.print("+++");
delay(1100);
//Serial.println("ATRE");
//Serial.println("ATD0 2");
//Serial.println("ATD5 2");
Serial.println("ATRP 40");
Serial.println("ATWR");
Serial.println("ATCN");
delay(2000);
digitalWrite(13,LOW);
pinMode(0,INPUT);
pinMode(5,INPUT);
pinMode(9,INPUT);
pinMode(greenLedPin, OUTPUT);
pinMode(redLedPin, OUTPUT);
incomming.setUpdateCallback(&dataUpdate);
SimpleSerialization.begin(connectionSpeed);
SimpleSerialization.addDeserializableData(&incomming);
attachInterrupt(0, readSer, CHANGE);
}
void loop() {
//digitalWrite(13,HIGH);
outgoing.setTitle("green_volt");
tmp = analogRead(5);
//delay(1);
outgoing.setData(tmp);
SimpleSerialization.write(&outgoing);
delay(10);
outgoing.setTitle("red_volt");
tmp = analogRead(0);
//delay(1);
outgoing.setData(tmp);
SimpleSerialization.write(&outgoing);
delay(10);
//digitalWrite(13,LOW);
}
void readSer()
{
SimpleSerialization.processInput();
}
Erwin
I ve got the Pro868 myself... and i am more than disappointed.
Have you or anyone found a work around and operate it with a highter duty cycle beyond ETSI regulations? Think I might be going to sell this crap again...
Jay
It features some way to limit transmitted data to a minimum to keep duty cycle low.
I tried 50 bytes, 9600bps, 25mW tx on PC side, 300mW tx on loopback.. With rather poor results until I put my finger on the loopback chip (the PC side was not really warm) to test if it was hot.
3sec max after I put my finger on the chip it started pushing 100% link, and every packet went through :P.
I really think cooling should help them work better than without.
Has there been any further tests/progress with these Xbee's?