You need to be a member of diydrones to add comments!
This reply was deleted.
Activity
RT @SahikaGenc: AWS DeepRacer & Hot Wheels Track https://youtu.be/4H0Ei07RdR4 via @YouTube
Great tutorial on getting started with @donkey_car
https://www.youtube.com/watch?reload=9&v=2z4aaTNnAvU&t=2449s&ab_channel=pajetech
RT @davsca1: We are releasing the code of our Fisher Information Field, the first dedicated map for perception-aware planning that is >10x…
RT @SmallpixelCar: How this works: 1)object detection to find cones in single camera image, 30 frames/sec on @NVIDIAEmbedded Xavier. 2)comp…
RT @SmallpixelCar: Use two color cones to guide the robocar. No map needed, on onsite training needed. Just place the cones and it will fol…
RT @roboton_io: Great to see http://roboton.io running at 60fps on the cheapest #chromebook we could find!
#edtech #robotics #educat…
RT @openmvcam: Crazy in-depth article about using the OpenMV Cam for Astrophotography:
https://github.com/frank26080115/OpemMV-Astrophotography-Gear https://t.co/BPoK9QDEwS
RT @openmvcam: Hi folks, it's finally here! Our first draft of our Arduino Interface Library is out! It works over SoftwareSerial, Hardware…
RT @chr1sa: Please let them have an open API. This would be perfect for @DIYRobocars races https://twitter.com/NintendoAmerica/status/1301513099707658246
RT @SmallpixelCar: Lanenet pretty much used all my GPU power on @NVIDIAEmbedded Xavier since I optimized with tensorRT. I need to run anoth…
RT @LyftLevel5: Our @kaggle competition on Motion Prediction for Autonomous Vehicles is now live! Experiment with the largest-ever self-dri…
RT @chr1sa: Our next @DIYRobocars virtual AI car race will be on Sept 26th. Sign up here
https://www.meetup.com/DIYRobocars/events/272786977/ https://t.co/UENKGSOWO8
New ready-to-run @NVIDIAEmbedded
JetRacer car from Waveshare. Perfect for the next @diyrobocars race as soon as we… https://twitter.com/i/web/status/1297960223013867520
RT @chr1sa: The US government just approved 5 US-made drones for purchase, all based on the @Dronecode @PX4Autopilot standard. Great news f…
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?
-
1
-
2
-
3
-
4
of 4 Next