I know this is not a big issue ,but I think we should all get on same page for pin assignment. I've change my setup to reflect Jeff's pin 1 and 0 xbee setup. I figure this setup is hard enough to get working without more confusion.
Brian
Great idea, and due to the number of configurations involved between iPads, pins, XBees, we should also provide direct references both the C and techBASIC code examples that run together, either by including them in the post or identifying where the compatible code lives in another post. Somehow I still manage to run mis-matched code.
As for the pin assignments, I strongly recommend we use what's used in the Learn.parallax.com resources for the ActivityBot.
@ Ken,
So that would be DO = pin 9 and DI = 8 ?( xbee tutorial), There is also and activity Bot tutorial that uses pin 8 for ping.
Also,
Are we creating a security issue in our home network by all of us using the same IP and Port address ? , I always change both of them ,but that has been adding confusion.
I agree that the software setup is a chore and that standardizing as much as possible is going to make things easier.
One of my biggest frustrations was the fact that initially none of us could get the same wifi configuration. I would like to see the current configuration verified with Digi as being a sound approach and then we could settle on an IP and Port and include it as a document in everything related to wifi. The option to modify IP and Port in the application is a bonus but by standardizing from the beginning it lessens the chances of having to go back and modify the settings.
@Brian, sorry for the change in I/O pins and I know I mixed the baud rate at times, if you can list a standard of all the pin assignments and baud rates I will attempt to stick with it. I like the C source you posted because it is easy to follow and it is modular, that is going to be important down the line. You did say your code was as clear as mushroom soup at one time which amused me, you know Microsoft had a codename for each of their OS's I think yours should be mushroom soup. That is not the truth though your code is very clear to me.
I want to mention byte(0) from the iPad it affects the constants in the C code. Each bit of byte(0) is a switch, the initial state when the app is started is R/C mode on, LED's off. That means byte(0) would look like this at start up
00000001 = 1 dec
switching LED1 toggles bit 4, so when LED1 is on and we are in R/C mode byte(0) looks like this
00010001 = 17 dec
which matches the constant. The issue is that if we were to change to Ping mode while leaving LED1 (bit 4) on then R/C (bit 0) would toggle off and Ping (bit 2) would toggle on, byte(0) would then look like this
00010100 = 20 dec
What I am saying is that R/C,Ping,Light,Halt,LED1 and LED2 can not be treated as constants but they should be read with a bit mask
I agree that the software setup is a chore and that standardizing as much as possible is going to make things easier.
One of my biggest frustrations was the fact that initially none of us could get the same wifi configuration. I would like to see the current configuration verified with Digi as being a sound approach and then we could settle on an IP and Port and include it as a document in everything related to wifi. The option to modify IP and Port in the application is a bonus but by standardizing from the beginning it lessens the chances of having to go back and modify the settings.
Jeff
Jeff, we have direct access to Digi WiFi engineers who can review what we're doing. I'd be happy to invite them in and make some comments on our setup for being a sound solution. What we're doing right now is an ad-hoc connection directly from iPad to XBee SB6 WiFi modules with a static IP and port number, correct? As I see it, we're only modifying two XBee WiFi parameters CO and MY. Am I correct or are most of us communicating with the XBee device through the router? Perhaps we have two common configurations we should have them inspect?
Thank you for the many contributions you and others are making to this project.
Ahh my haste to show an example of using defined messages and test comm speed
raised the issue of different serial pins , ip address
Sorry I should have thought of that.
@Ken
I am not sure you are saying you got it working and moved on to Jeff's good or not
If not I bet it is the serial pins I was using 10,11 as defined in my C code.
I will switch to 8,9 as in all the Activity Bot Learn tutorials.
If that is not the case I have had the same scree on iPad you show when I had turned off
the AB and my iPad switched back to my home network because it lost the connection to
the wifi XBEE. I have forgot to go back to the iPad WiFi settings and reconnect to the XBEE
after turning back on the AB and spent some time thinking I have great signal strength but nothing
is happening.
@Everyone
If you have the right ip address and serial pins and what I posted still does not show values coming back let me
know .
It would be a good test for everyone to do as the reason it works on some iPads and not others will apply to any code written.
To keep SimpleIDE code and TB code in sync when posting we can add the text file that we create by emailing the
TB code to ourself to the Zip file of the SimpleIDE project instead of positing it as a separate attachment.
@Brian
Are you using a router connection using your home router or a direct XBEE connection.
In the direct connection one issue I was concerned about is the fact that the ip address everyone likes 192.168.1.1 is the
same address for the setup web page my and I bet your home router. Now it is an http to that address but
I wondered if it by error would listen to the XBEE and mess something up. So I moved the XBEE direct to 192.168.1.3
For the home router network to XBEE the XBEE becomes just another user connected to the nework. When sending data
at 0.1 seconds a very busy user which when I was doing that brought the home network to slow mode for other connections.
It is not a good idea to standardize on one IP address for a local network. While it sounds simpler, in practice it is not. For example, some networks use 10.x.x.x while others use 192.x.x.x addresses. It should be possible to use an app to find the IP address of the device by the mac address on the S6B module.
Btw, Jeff and Brian, I think that C offers an opportunity for packet processing that you are missing with respect to parsing bits and bytes. The resulting code will be faster and far easier to maintain if you consider using structs and bit-fields as shown in this simple tutorial.
Below is some example code that demonstrates using a struct for parsing and stuffing bytes.
This is more complicated than just using an array, but it allows named byte fields. It is also a building block for understanding bit-fields which will be posted later.
/**
* This is the main bitfields program file.
*/
#include "simpletext.h"
/*
* This typedef defines a generic message struct
* used for stuffing and parsing bytes.
*/
typedef struct generic_st
{
char byte0;
char byte1;
char byte2;
char byte3;
char byte4;
char chksum;
} GenericMessage_t;
/* declare the generic message variable */
GenericMessage_t gmsg;
/* show payload and calculate checksum */
int checkSum(char *ptr, int payload_length);
/* main program */
int main(void)
{
// checksum variable
int chksum = 0;
// this calculates the length of the payload in the generic message struct
int payload_length = ((int)&gmsg.chksum-(int)&gmsg);
putLine("Message Struct demo");
putLine("\nStuff the message bytes.");
gmsg.byte0 = 0xA0;
gmsg.byte1 = 0x01;
gmsg.byte2 = 0x02;
gmsg.byte3 = 0x03;
gmsg.byte4 = 0x04;
putStr("\nByte 0 contains 0x");
putHex(gmsg.byte0);
putStr("\nByte 3 contains 0x");
putHex(gmsg.byte3);
putLine("\n\nCalculate the checksum");
chksum = checkSum((char*) &gmsg, payload_length);
putStr(" = 0x");
// print return value
putHex(chksum);
putStr(" = 0x");
// print value that was stuffed into the struct
putHex(gmsg.chksum);
putLine("");
return 0;
}
/*
* Calculate checksum showing the values and stuff the chksum byte.
* char *ptr is the address of the struct
* int payload_length is struct length minus 1. don't include the chksum.
* returns the chksum
*/
int checkSum(char *ptr, int payload_length)
{
int chksum = 0; // init checksum var
int j;
for(j = 0; j < payload_length; j++) {
if(j) putStr("+");
putStr("0x");
putHex(ptr[j]);
chksum += ptr[j];
}
ptr[j] = chksum;
return chksum;
}
@Tom,
Code looks like it functions well ,You might want to throw in a HOME or CLS in the terminal feedback. I have ran direct and through my router with the xbee ,both seem to work well.
@Jeff,
I would say pins 8 & 9 for xbee but I don't know what to do with the ping ?, I think we are on Cream of mushroom soup.stem 1
@Jazzed,
More reading ,Thanks . At least I can say It's starting to make sense.
@Brian
Good to hear on the code.
The program is an example of code for messaging as well as something to get a feel for
how the x,y,z values change as you wiggle the iPad around.
I was able to walk around the house today and even when I went to wifi drop out areas the code
recovered when I stepped back into an acceptable signal strength.
As far as the ping all you need to do is pick a different pin .
From the Parallax Learn Navigate by Ultrasonic
/* Test Ping.c Test the PING))) sensor before using it to navigate with the ActivityBot.*/
#include "simpletools.h" // Include simpletools header
#include "ping.h" // Include ping headerint distance;
// Declare distance variableint
main() // main function
{ while(1) // Repeat indefinitely {
distance = ping_cm(8); // Get cm distance from Ping)))
print("%c distance = %d%c cm", // Display distance HOME, distance, CLREOL); pause(200); // Wait 1/5 second }}
Just change the line distance = ping_cm(The new pin number you like);
Edit Thinking this morning maybe you were just asking Jeff how the ping sensor was going to be handled.
and you already knew the info above.
@jazzed
Thank's for the link, will give it a read.
For now I will keep making up the messages manually as I will only be debugging the code that uses them
not the code that makes them and the code that uses them.
The code I posted showing messaging is just a test program with everything lumped into one file. Long term
pulling message definitions into a separate header file is a better way. Even putting the message receive function
into a separate cog and hand shake with a flag , I have a message for you I am done with the last message you gave me.
@Jeff
Reading your code, I read the TB Manual on error handling first.
I like the way you did connecting.
Good work on that concept
Tom
ps Copy and paste ping code off of Parallax web page did not work to well it lost cr lf so I hand fixed it bit
best to look at or download code from site but I think you can get the idea .
Tom, what I would like to do if I get time this weekend is read over the TB code, add some comments and make the objects and variables more descriptive. I would also like to look over the sub routines and see if they can be improved, as part of this I am considering a new sub routine to handle the tx/rx side of things. The idea is a placeholder to run and test different protocols in a plug and play manner. Perhaps you can provide a sub routine with your A6 protocol that will just plug in this place holder. Whatever protocol is used will require a match at the C source, I looked at Steve's structure example and finally got it to sink in so anything that will fill that structure would also be a bonus.
Steve, do you already have a tutorial on the structure routine and its various implementations or is that tbd. Would the difficulty level be considered easy or perhaps easy to medium.
Brian, Digi have a blog I found describing adhoc connection XBee to XBee, their description did not work with the iPad as written so I made a couple of small changes listed in post #154
Steve, do you already have a tutorial on the structure routine and its various implementations or is that tbd. Would the difficulty level be considered easy or perhaps easy to medium.
I don't have any tutorials other than the code example. Andy writes the tutorials with beginners in mind.
Struct types usually come near the end of a CS101 class, so call them medium. The bit-fields tutorial I mentioned is more important though. Once you have some bits defined, I'll write an example for you.
Jeff
No problem on posting more on the messaging and an A6 sub idea.
I will do that later as I have somethings to do first today.
As far as Steve's Structure idea it is defining what is in a message and computing the length and checksum.
I do not know what you mean by asking him about various implementations, that is like asking if he has info on
various implementations of an array of bytes. In C a Structure is like a database record definition where you give
names and data types to each field of the record. In the case of messages a name and type to each part of the message
I have to finish an experiment later and will post I used a union to define the message because I want to overlay the received
bytes with a definition of the message content.
I want the routine receiving the data to treat the incoming stream as an array of bytes only and not care if it is getting a byte an integer
a long or part of a string. All it knows is it saw one of the message id's it knows and the next byte tells it how many more bytes to get
for this id and it then gets and checks the checksum. It stores the incoming bytes in an array that is the size of the largest message
that will come in.
Now on the C side it is an array of bytes for picking the bytes out of the receive message buffer again with out care as to what they mean
but by using a union which will overlay the Structure definition on the array of bytes I can then treat the message data with C types such as
integer long etc.
Having an array of bytes allows one to pack and unpack the message and if necessary flip the bytes around for endian issues.
meaning one side likes HOB LOB and the other LOB HOB for a 16 bit integer.
On the Tech Basic side we only have an array of bytes and no way to cleanly define message content.
The matching C data type for integer and TB is int16_t or uint16_t . On the C side they are 4 bytes for integers not two.
My experiment is to send -1000 as an integer from TB and see if I get $FC18 which is -1000 or $18FC which is 6396 indicating the two sides
are not the same byte order wise.
Sending the Ping sensor value as an integer is the reason.
If everything we ever send is a byte then byte order is a moot point there is none.
Brian, Jeff, Tom, Thomas, will you guys please let me know if you could benefit from any hardware for use in this project. It's getting hard to push stuff on you and I'm hoping you'll say "hey Ken, I could really use a [fill in blank here]".
I recently ran a set of code but couldn't get the XBee connection working for some reason. I'll check in later today and run whatever is posted this weekend.
Using "!DriveY" will turn the value into a boolean expression (1 or 0). So, if DriveY contained any value other than 0, it will become 0. If it contained 0, it will become 1. ! is a logic NOT.
Did you mean "-DriveY"? Which is a negative operation...
@Jeff,
Yes the pin thing was the first thing I checked .I've checked the xbee configuration and everything else I can think of ,still no com between the xbee and Ipad . I tried through my router and direct , nothing.
@dgately,
My goal with !DriveY was to get the opposite number if the number was 50 I wanted -50 if the number was -100 I wanted 100 . I used my programmer's calc to test flipping bits and it was only one off. The Actbot drove and steered just fine until lost communications and hasn't worked since.
Hi Brian, you have probably done this but I will post it just in case there is something that might help. This is for direct connection.
The first thing is to set up a connection between the iPad and XBee, which I guess is where your problem is. Connect the XCTU software to the XBee and write the default settings, the XCTU software even has an option to recover an unresponsive module.
If you can get past that step then load the following settings. Make sure any cellular connection you might have is switched off and that only wifi is enabled
Configuring an adhoc network for the XBee S6B.
If you have altered settings and are not sure what you altered use the xctu software to reset to the default firmware and write the default settings. Then enter the settings below.
AH1 IBSCreator
CE1 Soft AP mode
ID <TYPE A NAME FOR YOUR NETWORK>
IP1 TCP
MA1 Static
GW 192.168.1.1
MK 255.255.255.0
MY 192.168.1.1
At the iPad leave the default which should be IP Address DHCP and HTTP Proxy off. After configuring the XBee it will take several seconds for the iPad wifi to connect to the XBe, this will be indicated by the name you gave the ID with a blue check mark next to it.
When using techBasic to connect the ip will be 192.168.1.1 and the port number will be 9750.
Let us know how far you can get with that and if you can even connect with XCTU.
@Brian
Have you tried some other program like my code you said the other day was working and displaying
values and you tried it with your router and direct.
Go back and see if that still works.
And on that note maybe in doing that you re programmed the XBEE for router use
Edit: Also inverting all the bits and adding 1 produces what is called the two's complement of a number
and that is the negative . However that is not how Jeff and Thomas did the scaling of Acell values.
They just have values less than 127 and greater than 127 all positive.
I would be concerned since ABDrive functions take integers as parameters that inverting bits to get a
negative would cause some wild moving around .
@Jeff
Doing some debugging before I post more on messages
On the down side I finally did iTunes and grabbed your images and tried your TB code to see what
it looked like and on my iPad with Retnia display the images to not work. Things are in the wrong place
and somethings overlap.
In xcode apps that work with both older iPads and newer ones with the high res Retnia dispaly require
1X and 2X image files for each image.
I will try and get a pic but I have had no luck doing that with my iPad, will try Ken's way but that will be tomorrow
@dgately,
My goal with !DriveY was to get the opposite number if the number was 50 I wanted -50 if the number was -100 I wanted 100 . I used my programmer's calc to test flipping bits and it was only one off. The Actbot drove and steered just fine until lost communications and hasn't worked since.
Understand that you're working on the more immediate problem. But, once you get communications working again you'll want to fix the problem with using !, as it won't flip bits, but gives only a Boolean result.
Hi Tom, I have the iPad Air with Retina and they display fine or are you saying you have an older model where things overlap. I don't yet see anything in techBasic that mentions this might be a problem, do you have any links for reference it is certainly something to look at.
Jeff
It is a year old, I believe the one before they changed the name to iPad air because of the new mini's
It has the new small usb cable not the older 30pin connector.
I will try and grab a pic.
@Brian
To invert the bits use the tilde "~" as in ~speed which will invert all bits of speed. ~speed +1 gives 2"s complement which is negative of speed
Maybe more proper to say 2's complement is how negative numbers are stored.
I say this for your C knowledge I am not convinced it is the way to go for the calculation you are trying to do however.
Tom this is what I have read about the ImageView class that may help. Lets look at the largest graphic as an example, the AB_Ping.gif is contained in an ImageView control with the following declaration.
DIM img AS imageview
img=graphics.newimageview(350,100)
img.loaDIMage("AB_Ping.gif")
The manual says that the behavior of the above is for the ImageView control to resize to the size of the image. There is a second option where the ImageView control can be a fixed size and the image will resize.
I have not tried this yet but I am assuming that if we fix the ImageView control at a certain size and specify "resize=0" for LoadImage then we would have control of how our image is displayed. For example if our image had dimensions of 400 x 800 and we wanted to scale it down 50% we would modify the above declaration as follows
DIM img AS imageview
img=graphics.newimageview(350,100,200,400)
img.loaDIMage("AB_Ping.gif",0)
I was under the impression that all iPads had the same screen resolution, although this is specified in points and not pixels I have read where the OS takes care of the pixel side of things, which made me wonder if it was related more to the OS version than the screen. If that was the case things would be much easier as TB has the osVersion function we could use to determine what scale would be required.
I am just guessing right now, lets first see if we can make headway by fixing the size of the image with a variation of the above declaration.
@Brian
Do both the blue and red led's next to the XBEE on the Activity Board flash when you are trying to send and receive
If they flash the RF part is working in both directions and then I think of serial connection on wrong pin. If only one LED
flashes then it is an XBEE issue
If it will help with XBEE direct connections, Ken last said he lost his and Brian also here
is my XCTU working setup.
xb001 is just a name I made up and what you should see in the iPad Wifi Settings to select as a connection.
Note I am at ip .3 becuase I do not want to be at same as home router so I moved it up a bit
In my iPad to ActivityBot app, which uses Bluetooth LE, I send config info to the XBee module from the ActivityBot board either at the start of my code or as a separate program that runs "just once" to configure the XBee module. The Bluetooth LE commands in this C-code sample below are obviously not compatible with the WiFi XBee but give an example of how I configure my BT XBee module.
This code could be easily modified to query a bot owner via the Console for a name and IP address, if that is needed. Or, one could query the local network (if DHCP and ZeroConf is enabled) for a server that provides either a school-provided name or an unused one. And, might allow getting the assigned IP number as well. This code could exec needed XBee WiFi commands to configure the XBee and might even save info in the bot's eeprom, much like in Andy's ActivityBot calibration examples.
void configureBT(fdserial * driver) {
// HMSoft Bluetooth Module commands to configure for use as a peripheral device
writeCommand(driver, "RENEW"); // reset all settings
writeCommand(driver, "NAMESUMBOTY"); // set this device's name 'WALL-E' (12 chars MAX)
writeCommand(driver, "ROLE0"); // ROLE0 is 'peripheral', ROLE1 is 'central'
writeCommand(driver, "MODE2"); // MODE0 = Transmission Mode, MODE1 = Remote Control Mode, MODE2 = Modes 0 + 1
writeCommand(driver, "TYPE0"); // TYPE0 = NO PIN code needed (may want to change this to require PIN code)
writeCommand(driver, "NOTI1"); // NOTI1 set to notify when conncted or when connection is lost (OK+CONN or OK+LOST)
writeCommand(driver, "IMME1"); // IMME1 = wait until "AT+START" to start comms (IMME0 start coms when powered-on)
// HMSoft Bluetooth Module commands to configure support connection to iOS device
writeCommand(driver, "ADVI1"); // set Advertising interval to: 1 == 1285ms (iOS safe)
writeCommand(driver, "IBEA1"); // turn on the iBeacon (IBEA0 would turn iBeacon off)
writeCommand(driver, "BUSHU"); // set iBeacon into service mode
writeCommand(driver, "START"); // start-up the communication
}
void writeString(fdserial * driver,char * string) {
for (int i = 0; i < strlen(string); i++) { // send a string to HMSoft Bluetooth module
writeChar(driver,string[i]);
}
}
void writeCommand(fdserial * driver, char * atCommand) {
// HMSoft Bluetooth Module expects "AT+COMMAND_STRING"
writeString(driver, "AT+");
writeString(driver, atCommand);
pause(100); // AT+ commands need time to exec
}
BTW: The above code advertises my ActivityBot to the Bluetooth LE world (it acts as an iBeacon). My iPad generally finds the bot within about a half-second. Wouldn't it be nice of the current WiFi solution worked as quickly?
My assumption is that in a classroom environment that the bot (actually it's WiFI XBee module) gets assigned an IP via DHCP and a name before the bot is given to a student. This makes sure that there are no name conflicts as some majority of students will want to name their bot "Terminator", "ROBBY", "WALL-E" or other common robot themed name...
@Tom, the graphics look normal in the screen shot, the background is not right because it has not been told to resize or repaint after being rotated.
The app in my mind is best suited to work in landscape orientation and I had not got around to eliminating the use of portrait orientation. Try including the following line at the head of the source code and see if that corrects the situation.
Comments
Great idea, and due to the number of configurations involved between iPads, pins, XBees, we should also provide direct references both the C and techBASIC code examples that run together, either by including them in the post or identifying where the compatible code lives in another post. Somehow I still manage to run mis-matched code.
As for the pin assignments, I strongly recommend we use what's used in the Learn.parallax.com resources for the ActivityBot.
Thanks,
Ken Gracey
So that would be DO = pin 9 and DI = 8 ?( xbee tutorial), There is also and activity Bot tutorial that uses pin 8 for ping.
Also,
Are we creating a security issue in our home network by all of us using the same IP and Port address ? , I always change both of them ,but that has been adding confusion.
Brian
One of my biggest frustrations was the fact that initially none of us could get the same wifi configuration. I would like to see the current configuration verified with Digi as being a sound approach and then we could settle on an IP and Port and include it as a document in everything related to wifi. The option to modify IP and Port in the application is a bonus but by standardizing from the beginning it lessens the chances of having to go back and modify the settings.
@Brian, sorry for the change in I/O pins and I know I mixed the baud rate at times, if you can list a standard of all the pin assignments and baud rates I will attempt to stick with it. I like the C source you posted because it is easy to follow and it is modular, that is going to be important down the line. You did say your code was as clear as mushroom soup at one time which amused me, you know Microsoft had a codename for each of their OS's I think yours should be mushroom soup. That is not the truth though your code is very clear to me.
I want to mention byte(0) from the iPad it affects the constants in the C code. Each bit of byte(0) is a switch, the initial state when the app is started is R/C mode on, LED's off. That means byte(0) would look like this at start up
00000001 = 1 dec
switching LED1 toggles bit 4, so when LED1 is on and we are in R/C mode byte(0) looks like this
00010001 = 17 dec
which matches the constant. The issue is that if we were to change to Ping mode while leaving LED1 (bit 4) on then R/C (bit 0) would toggle off and Ping (bit 2) would toggle on, byte(0) would then look like this
00010100 = 20 dec
What I am saying is that R/C,Ping,Light,Halt,LED1 and LED2 can not be treated as constants but they should be read with a bit mask
Jeff
Jeff, we have direct access to Digi WiFi engineers who can review what we're doing. I'd be happy to invite them in and make some comments on our setup for being a sound solution. What we're doing right now is an ad-hoc connection directly from iPad to XBee SB6 WiFi modules with a static IP and port number, correct? As I see it, we're only modifying two XBee WiFi parameters CO and MY. Am I correct or are most of us communicating with the XBee device through the router? Perhaps we have two common configurations we should have them inspect?
Thank you for the many contributions you and others are making to this project.
Ken Gracey
raised the issue of different serial pins , ip address
Sorry I should have thought of that.
@Ken
I am not sure you are saying you got it working and moved on to Jeff's good or not
If not I bet it is the serial pins I was using 10,11 as defined in my C code.
I will switch to 8,9 as in all the Activity Bot Learn tutorials.
If that is not the case I have had the same scree on iPad you show when I had turned off
the AB and my iPad switched back to my home network because it lost the connection to
the wifi XBEE. I have forgot to go back to the iPad WiFi settings and reconnect to the XBEE
after turning back on the AB and spent some time thinking I have great signal strength but nothing
is happening.
@Everyone
If you have the right ip address and serial pins and what I posted still does not show values coming back let me
know .
It would be a good test for everyone to do as the reason it works on some iPads and not others will apply to any code written.
To keep SimpleIDE code and TB code in sync when posting we can add the text file that we create by emailing the
TB code to ourself to the Zip file of the SimpleIDE project instead of positing it as a separate attachment.
@Brian
Are you using a router connection using your home router or a direct XBEE connection.
In the direct connection one issue I was concerned about is the fact that the ip address everyone likes 192.168.1.1 is the
same address for the setup web page my and I bet your home router. Now it is an http to that address but
I wondered if it by error would listen to the XBEE and mess something up. So I moved the XBEE direct to 192.168.1.3
For the home router network to XBEE the XBEE becomes just another user connected to the nework. When sending data
at 0.1 seconds a very busy user which when I was doing that brought the home network to slow mode for other connections.
Tom
Tom
Btw, Jeff and Brian, I think that C offers an opportunity for packet processing that you are missing with respect to parsing bits and bytes. The resulting code will be faster and far easier to maintain if you consider using structs and bit-fields as shown in this simple tutorial.
Below is some example code that demonstrates using a struct for parsing and stuffing bytes.
This is more complicated than just using an array, but it allows named byte fields. It is also a building block for understanding bit-fields which will be posted later.
Code looks like it functions well ,You might want to throw in a HOME or CLS in the terminal feedback. I have ran direct and through my router with the xbee ,both seem to work well.
@Jeff,
I would say pins 8 & 9 for xbee but I don't know what to do with the ping ?, I think we are on Cream of mushroom soup.stem 1
@Jazzed,
More reading ,Thanks . At least I can say It's starting to make sense.
Thanks'
Brian
Good to hear on the code.
The program is an example of code for messaging as well as something to get a feel for
how the x,y,z values change as you wiggle the iPad around.
I was able to walk around the house today and even when I went to wifi drop out areas the code
recovered when I stepped back into an acceptable signal strength.
As far as the ping all you need to do is pick a different pin .
From the Parallax Learn Navigate by Ultrasonic Just change the line distance = ping_cm(The new pin number you like);
Edit Thinking this morning maybe you were just asking Jeff how the ping sensor was going to be handled.
and you already knew the info above.
@jazzed
Thank's for the link, will give it a read.
For now I will keep making up the messages manually as I will only be debugging the code that uses them
not the code that makes them and the code that uses them.
The code I posted showing messaging is just a test program with everything lumped into one file. Long term
pulling message definitions into a separate header file is a better way. Even putting the message receive function
into a separate cog and hand shake with a flag , I have a message for you I am done with the last message you gave me.
@Jeff
Reading your code, I read the TB Manual on error handling first.
I like the way you did connecting.
Good work on that concept
Tom
ps Copy and paste ping code off of Parallax web page did not work to well it lost cr lf so I hand fixed it bit
best to look at or download code from site but I think you can get the idea .
Are you using the Xbee in transparent mode or did you set to API for built in error checking ?
Brian
Steve, do you already have a tutorial on the structure routine and its various implementations or is that tbd. Would the difficulty level be considered easy or perhaps easy to medium.
Brian, Digi have a blog I found describing adhoc connection XBee to XBee, their description did not work with the iPad as written so I made a couple of small changes listed in post #154
Jeff
I don't have any tutorials other than the code example. Andy writes the tutorials with beginners in mind.
Struct types usually come near the end of a CS101 class, so call them medium. The bit-fields tutorial I mentioned is more important though. Once you have some bits defined, I'll write an example for you.
Struct types are mentioned in chapter 6 of the link dgately found: http://www.cs.rochester.edu/u/brown/172/readings_texts/KR.pdf That pdf of the K&R ANSI C book could disappear. Save a copy if you can.
No problem on posting more on the messaging and an A6 sub idea.
I will do that later as I have somethings to do first today.
As far as Steve's Structure idea it is defining what is in a message and computing the length and checksum.
I do not know what you mean by asking him about various implementations, that is like asking if he has info on
various implementations of an array of bytes. In C a Structure is like a database record definition where you give
names and data types to each field of the record. In the case of messages a name and type to each part of the message
I have to finish an experiment later and will post I used a union to define the message because I want to overlay the received
bytes with a definition of the message content.
I want the routine receiving the data to treat the incoming stream as an array of bytes only and not care if it is getting a byte an integer
a long or part of a string. All it knows is it saw one of the message id's it knows and the next byte tells it how many more bytes to get
for this id and it then gets and checks the checksum. It stores the incoming bytes in an array that is the size of the largest message
that will come in.
Now on the C side it is an array of bytes for picking the bytes out of the receive message buffer again with out care as to what they mean
but by using a union which will overlay the Structure definition on the array of bytes I can then treat the message data with C types such as
integer long etc.
Having an array of bytes allows one to pack and unpack the message and if necessary flip the bytes around for endian issues.
meaning one side likes HOB LOB and the other LOB HOB for a 16 bit integer.
On the Tech Basic side we only have an array of bytes and no way to cleanly define message content.
The matching C data type for integer and TB is int16_t or uint16_t . On the C side they are 4 bytes for integers not two.
My experiment is to send -1000 as an integer from TB and see if I get $FC18 which is -1000 or $18FC which is 6396 indicating the two sides
are not the same byte order wise.
Sending the Ping sensor value as an integer is the reason.
If everything we ever send is a byte then byte order is a moot point there is none.
Tom
More later
Tom
I recently ran a set of code but couldn't get the XBee connection working for some reason. I'll check in later today and run whatever is posted this weekend.
Ken Gracey
Something changed, I can't get anything working that we had working. I've checked everything from pin assignments to battery power.
I had the actBot moving around with this code when everything went to heck. I was using Jeffs code from post 203 (no error checking)
Brian
EDIT: Removed code , I think it was over running memory.
Jeff
EDIT I was also a little confused with xbee_recieve_pin when that is actually the Activity Bot's receive pin
Brian,
What is this statement supposed to do?
Using "!DriveY" will turn the value into a boolean expression (1 or 0). So, if DriveY contained any value other than 0, it will become 0. If it contained 0, it will become 1. ! is a logic NOT.
Did you mean "-DriveY"? Which is a negative operation...
dgately
Yes the pin thing was the first thing I checked .I've checked the xbee configuration and everything else I can think of ,still no com between the xbee and Ipad . I tried through my router and direct , nothing.
@dgately,
My goal with !DriveY was to get the opposite number if the number was 50 I wanted -50 if the number was -100 I wanted 100 . I used my programmer's calc to test flipping bits and it was only one off. The Actbot drove and steered just fine until lost communications and hasn't worked since.
Thanks'
Brian
The first thing is to set up a connection between the iPad and XBee, which I guess is where your problem is. Connect the XCTU software to the XBee and write the default settings, the XCTU software even has an option to recover an unresponsive module.
If you can get past that step then load the following settings. Make sure any cellular connection you might have is switched off and that only wifi is enabled
Let us know how far you can get with that and if you can even connect with XCTU.
Jeff
Have you tried some other program like my code you said the other day was working and displaying
values and you tried it with your router and direct.
Go back and see if that still works.
And on that note maybe in doing that you re programmed the XBEE for router use
Edit: Also inverting all the bits and adding 1 produces what is called the two's complement of a number
and that is the negative . However that is not how Jeff and Thomas did the scaling of Acell values.
They just have values less than 127 and greater than 127 all positive.
I would be concerned since ABDrive functions take integers as parameters that inverting bits to get a
negative would cause some wild moving around .
@Jeff
Doing some debugging before I post more on messages
On the down side I finally did iTunes and grabbed your images and tried your TB code to see what
it looked like and on my iPad with Retnia display the images to not work. Things are in the wrong place
and somethings overlap.
In xcode apps that work with both older iPads and newer ones with the high res Retnia dispaly require
1X and 2X image files for each image.
I will try and get a pic but I have had no luck doing that with my iPad, will try Ken's way but that will be tomorrow
Tom
Understand that you're working on the more immediate problem. But, once you get communications working again you'll want to fix the problem with using !, as it won't flip bits, but gives only a Boolean result.
Good luck!
dgately
Jeff
It is a year old, I believe the one before they changed the name to iPad air because of the new mini's
It has the new small usb cable not the older 30pin connector.
I will try and grab a pic.
@Brian
To invert the bits use the tilde "~" as in ~speed which will invert all bits of speed. ~speed +1 gives 2"s complement which is negative of speed
Maybe more proper to say 2's complement is how negative numbers are stored.
I say this for your C knowledge I am not convinced it is the way to go for the calculation you are trying to do however.
Tom
DIM img AS imageview
img=graphics.newimageview(350,100)
img.loaDIMage("AB_Ping.gif")
The manual says that the behavior of the above is for the ImageView control to resize to the size of the image. There is a second option where the ImageView control can be a fixed size and the image will resize.
I have not tried this yet but I am assuming that if we fix the ImageView control at a certain size and specify "resize=0" for LoadImage then we would have control of how our image is displayed. For example if our image had dimensions of 400 x 800 and we wanted to scale it down 50% we would modify the above declaration as follows
DIM img AS imageview
img=graphics.newimageview(350,100,200,400)
img.loaDIMage("AB_Ping.gif",0)
I was under the impression that all iPads had the same screen resolution, although this is specified in points and not pixels I have read where the OS takes care of the pixel side of things, which made me wonder if it was related more to the OS version than the screen. If that was the case things would be much easier as TB has the osVersion function we could use to determine what scale would be required.
I am just guessing right now, lets first see if we can make headway by fixing the size of the image with a variation of the above declaration.
Jeff
I can configure xbee's in XCTU program.
Can send data one way from the I pad to xbee's. No date coming back out of xbee or Ipad not receiving data from xbee.
The wifi on the ipad works just fine for getting on the internet. Seems like a ipad issue but not sure.
Any thoughts?
Thanks'
Brian
Here is what my iPad screen looks like with your images.
Sorry for the delay, I was a bit busy last few days getting snow out of driveway.
Do both the blue and red led's next to the XBEE on the Activity Board flash when you are trying to send and receive
If they flash the RF part is working in both directions and then I think of serial connection on wrong pin. If only one LED
flashes then it is an XBEE issue
is my XCTU working setup.
xb001 is just a name I made up and what you should see in the iPad Wifi Settings to select as a connection.
Note I am at ip .3 becuase I do not want to be at same as home router so I moved it up a bit
This code could be easily modified to query a bot owner via the Console for a name and IP address, if that is needed. Or, one could query the local network (if DHCP and ZeroConf is enabled) for a server that provides either a school-provided name or an unused one. And, might allow getting the assigned IP number as well. This code could exec needed XBee WiFi commands to configure the XBee and might even save info in the bot's eeprom, much like in Andy's ActivityBot calibration examples.
BTW: The above code advertises my ActivityBot to the Bluetooth LE world (it acts as an iBeacon). My iPad generally finds the bot within about a half-second. Wouldn't it be nice of the current WiFi solution worked as quickly?
My assumption is that in a classroom environment that the bot (actually it's WiFI XBee module) gets assigned an IP via DHCP and a name before the bot is given to a student. This makes sure that there are no name conflicts as some majority of students will want to name their bot "Terminator", "ROBBY", "WALL-E" or other common robot themed name...
dgately
The app in my mind is best suited to work in landscape orientation and I had not got around to eliminating the use of portrait orientation. Try including the following line at the head of the source code and see if that corrects the situation.
Jeff
Working now ,the IP mask got changed and resetting the xbee does not fix it. I entered your setup and it works fine again.
Thanks'
Brian