As soon as we agree that 1.1 is ready we merge it back into the trunk version and we can start a 1.2 or 2.0 branch.
@rich: yes, 915 and 315 are not allowed in europe and 868 and 443 are probably not allowed in the US, however using ATCF the end user can select the proper bands (when we get that to work ) without having to load an IDE, comment out one band and remove comments on the other. To me that sounds like a plus. The cc1101 used in the RFbee also allows all bands so I donāt think we are violating the law here if we build a layer on top of that. Its the users responsibility to select a band which is allowed in his/her country.
With regards to the probing of the error, is there any difference when using interrupt receive and non interrupt receive ?
Thanks for the reshuffle and reminding me on the band info, actually some people can use 443 in the US, it is a ham band as a secondary allocation. I just want to make sure I was setting legal bands by default. At this power level it will be hard to be noticed, but it is wise to stay legal.
I will set things up tomorrow for a test without interrupts defined.
@Icing, is the antenna cut for a particular frequency?
Hans, thanks for the more clear orgnization of the google code structure.
rich, the antenna lenght of RFBee is for 915MHz,(Ī»/4). If working 868 or 433 longer antenna may get the best effect. BTW, the hardware design of RFBee is not for 433 or 315 (refer to the datasheet of cc1101), so it may not work in these two bands.
there is a bug in MD_command, it will not accept values 3 and 4 at the moment. I reworked the code.
I also added a E1 command to do local echo so I could see what I typed in command mode. (Yes my typing is bad)
In transceive mode I get no communication.
Commented out interrupt_receive and I still get no communication.
Testing device 2 transmit device 1 receive. Yeah every 4 chars is sent and received. Did several lines enough to be fairly confident.
Device 1 transmit > device 2. Hmm not so good, The first 4 chars are sent, then device 2 reports rfdata error, and nothing more appears. Device 2 keeps accepting data, but Nothing more comes out of Device 2. Note it took power off of both devices to repeat the test. Same result 3 times in a row?
Back to the Arduino IDE renabled interrupt_receive.
Did the same test
Device 2 transmits to device 1. Past the same as above. This is good
Device 1 trans to Device 2. No characters pass, then endless output of
Error: Received invalid RF data size
Error: Received invalid RF data
until I reset both boards. So no data travels here. Puzzling away.
More puzzling I noticed a change had been made to RFBee.pde so I pick it up. Now nothing works, version 23 according to svn.
Maybe things are not so bleak, but there are plenty of issues. I rebuilt with interrupts enabled. At first no joy but this time the receiving device got an error at the end of the first line, then started receiving??
*****Sending device
ok
atcf
2
ok
atmd1
ok
This is a test that is not working
it did give me some errors then it started working
******Receiving device:
atcf2
ok
atmd2
ok
Error: Received invalid RF data
st tError: Received invalid RF data
Error: Received invalid RF data
it did give me some errors then it started working
I also tried the opposite direction, and was able to get a few packets to go through. That is I saw the rf errors after typing for a line of ~25 characters, then 4 chars came out, then nothing then 4 later chars, then an rf error, then one more set of 4. I see this only if I keep sending characters, and the reception is a small fraction the input.
********Other device receiving
+++ok, starting cmd mode
atmd2
ok
Error: Received invalid RF data
therError: Received invalid RF data
Error: Received invalid RF data
ļæ½Error: Received invalid RF data
justasioError: Received invalid RF data
*******Sending device
+++ok, starting cmd mode
atmd1
ok
just occasionaly apackats\thrhough the other device to start working?
****(The text wrapped over itself so I lost most of the first line to overstrike. I still am finishing my local echo mode)
small update: thereās good news and thereās bad news
The good news is that:
a) today my cabling came in and I managed to get some bytes across the air.
b) I fixed the MD command
c) I created a receive data which returns data and a write serial which writes the received data to serial, based on the OF setting
The bad news is that I updated my code to fix items b and c, but somehow no data is transferred across the air any more.
So I need to do some more debugging
atrs (reset the config, to ensure the eeprom values match this version of the code)
ato0 (back to online mode)
This one works on my pair of bees, any input on the serial of RFbee 1 shows up on the output of RFbee 2.
With output format (ATOF) set to 0 (is the default) this means you now have a virtual wire
I set the default for rfBeeMode to transceive_mode so it works both ways out of the box.
The interrupt_receive handler is currently a bit of mess, so please do not enable it.
I was thinking to integrate the firmata protocol ( firmata.org/wiki/Main_Page )
Its common software for arduino (lib is available in the IDE) and seems to take about 1 KB of flash. If we then add a ATMD 5 being firmata then we can do the following:
rfBee1 in mode 3 (transceive) connected to a PC
rfbee2 in mode 5 (firmata) connected to I/O (leds, steppers etc)
any firmata command (e.g. Digital 10 HIGH) send via USB from rfbee 1 will be executed by rfBee 2.
As there is plenty of host software (python , flash etc) available, it will be a breeze to integrate
My suggestion would be to emit any received firmata traffic (wile in MD 5) on the serial as well to aid in debugging
Then some small improvements, I think we should:
set the default for threshold (ATTH) to 1 as its not intuitive for users that data is only send in multiples of 4 bytes.
persist the rfbeeMode (ATMD) value, so the bee will still be in whatever mode after reset.
small question: did you ever get the RFbee (e.g. 1.03 or older) working on 868Mhz ?
ATCF 2 and ATCF 3 do not give me a working connection, now it could be that I need to play with SmartRF Studio, but it would be nice to know if it ever worked before
Well, itās ok,and I ever thought of that. However if threshold is set to 1, it will decrease the transmit efficiency. We need to give advice to users to set the threshold as long as possible.
Yes, it will be very well and is much easier to implement in your new version than seeed v1.0.
The rfbee(hardware v1.0) works ok in 868MHz, and weāv tested that. However, rfbee(hardware v1.1)is not tested in 868MHz, so at which frequency we not sure if it works ok with software v1.0 or v1.1a2. As it is in weekend, I do not have rfbees in hand to test that. You may use sofware v1.0 to test the new rfbees working in 868MHz.
BTW, I also met the similar problem as I was debugging the code you committed(using hardware v1.1). As I use v1.03 send data in 915MHz with datarate 1200, the rfbees can not transceive data with each other.
However, when I use one rfbee with software v1.03 send data in 1200 datarate to the rfbee with sofware v1.1a2, the later received. So it is the problem of the transmitting with v1.1a2.
I checked the difference of the settings between v1.03 and v1.1a2, they are the same.
This also made me confused.
So I guess the biggest difference between two version is the state of rfbee after transmitting.
In v1.1a2, the rfbee retrun to idle state, while in v1.03 the rfbee stay in transmit state. I also met this problem even when I debugg the software v1.1a2 working in 915MHz, so I add delay(5) after transmitting in function transmitData().
May it useful to your debugging. And Iāll look into it next week.
just commited R25 with the small suggestions applied. ATMD is now persisted and ATTH now has 1 as default.
I loaded my bees (hardware 1.1) with firmware 1.01, 915Mhz works fine, but 868Mhz fails.
I would expect that it does not matter for the CCx whether it sends on 868 or 915 apart from some clock pulse. My first guess would be that we need to fix another clock parameter, or need to give the bee more time to rescale the clock. When I have some time Iāll check the datasheet to look for clues
Great work I will be testing here seeing if I can figure any of it out. This is becoming much easier to work with. I like your firmata suggestion. I am off to look into that more, but it seems like what I was wanting. I am still seeing very random communication where it works well for a short while then stops for quite a while, then starts up again. I am seeing more errors than before which i few as a good sign, but there is still clearly some confusion. Also I noticed the size is down!
random errors could be due to interference with other devices in the neighbourhood. (e.g. weather stations etc)
The ISM band (see http://en.wikipedia.org/wiki/ISM_band ) is pretty wild west. The only way succesfull transmission is possible is because it is assumed (dangerous word here ) that all transmitters only send a small percentage of the time (e.g. less than 1%). Most devices I have seen will send the same message 3 times, hoping that at least one instance will survive collisions with other transmissions. As 915Mhz is uncommon in Europe, I get perfect transfers , as soon as I get 868 working I expect to see more collisions.
Alternatively one could use a ack protocol to get a more robust stack. Or if you want to be creative (:-)): something like automated channel hopping, or a micro tcp/ip stack
Did some test, and see the updating of google code r27.
Changes:
1.Set rfbee into proper state after tx,rx, as in seeed v1.03.
2. Remove the delay(5) after CCx.Strobe(CCx_STX) in transmitData().
Reason:
ATCF0~3 all works now.
Issues:
The data length you send to the rfbee should be the same as the threshold every
time. Otherwise, the receiving rfbee will receive invalid data endlessly as rich has met.
The problem may exist in:
Transmit process.(As I use v1.03 as transmitter, v1.1_r26 as receiver, it works
ok). And I dont think it is the interuption by the other signal in ISM surrounding us.
did some major rework , see the updating of google code r27.
Simple config only commands (e.g. atth etc) are now handled in a standard way (modifyConfig)
AT commands that actually need to do something (e.g. ATCF to change config and CCx settings) follow the standard way and then, as post processing call a function defined in the command table. (setCCxConfig() for ATCF)
Commands that donāt change config (e.g. ATRS), have 0 digits, and therefore only execute the post processing call.
The 915/868 is still a mystery to me.
Over here ATCF0 and ATCF2 works, but ATCF1 and ATCF3 not.
seems like the 1.2 baud is picking up noise in my environment as I can not think of another explanation because it seems to work in your environment.
If you have some time, can you load r27 on your end and see if CF0~3 all work ?
I use threshold value 1 and overflowing that produces no errors.
Could be though that CCx_PACKT_LEN needs to be shortened to 61 as per section 15.3 of the datasheet (CCx_FIFO_SIZE - 3 bytes)
So that if you try to send say 80 bytes at once, it will first send 61 and then the remaining 19.
Just updated. I will try to test. The two devices where so close last time, that no other possible radiator would have had a chance. (I am a ham and I am well aware of where all the transmitters around me are located. noise sources are something I am always having to find.) I was concerned of possible over drive issues given the .25 M separation.
Looks like youāre all doing a ton of good work. Iāve been lurking around a bit and trying to get the firmware on my RFbees up to the latest and mostly working files. I took all the files from the Google code library, compiled, uploaded, and I was faced with this:
[size=85]rfBeeInit:
setCCxConfig:
setMyAddress:
setAddressCheck:
setPowerAmplifier:
setRFBeeMode:
ok
writeSerialData:
receiveData:
writeSerialError:
error: received invalid RF data size
writeSerialData:
receiveData:[/size]
and on in to infinity.
Issuing an ATRS met with no results. Iām running hardware V1.1. This has happened on all of my units. I know I should be able to revert to an older firmware.
Hereās the thingā¦ I have a simple wireless job Iām trying to run, literally I need two bytes of data to set some LEDs on PD5 and PD6, so I figured the RFbee would have enough residual horsepower to at least pull that off. I know weāre up against a RAM wall here, so this is why Iām looking to the newest code, since it looks like you guys have been doing a bang-up job of getting the RAM size down. What exactly is going on here? Is it that the EEprom is set up with disagreeable values? The firmware compiles OK, but is there a chance that I have different files from different versions? Where do I look (in google code I assume) for the whole package of the latest firmware? trunk? branch?
Thanks! (and forgive me if Iām in violation of the open source code development protocol, Iām just some yahoo trying to make a public art project happen here in Brooklyn!) Iāve done plenty of PIC programming and a whole bunch of electronic work, so Iām not a complete newbie, Iāve just never participated in an open source project.
The latest firmware you are using is still not reliable as I met the same error as you. You may try this: The data length you send to the rfbee should be the same as the threshold every
time, otherwise, the receiving rfbee will receive invalid data endlessly. (However, it does not happen on Hans)
If just control PD5 and PD6, I think firmware v1.01 is no problem, and you may need to do some small changes in the ISR receiving function.
Yes, firmware v1.1 has much free RAM than v1.01 or v1.03, and the structure is more clear. However it is not steady now.
Yes, the data perestored to the EEPROM is different.
Use SVN you can get different versions(latest or older) from branch.
seeed is trying to do more open source project, and we are glad to hear any suggestion or advice to make the platform much better.
May this helpful to you, and feel free to ask any question!
) is now in rfbee.googlecode.com/svn/branches/v1.1/RFBee