@mrollin, the bottle neck in data throughput is between the PIC (or ATmega) and the RFduino on the board. For reasons having to do with the way RFduino handles radio interrupts vs serial interrupts, 115200 is the max baud that is stable. That combined with the maximum radio packet size.
The uC wants to send 31 bytes per sample
1 byte sample counter
8-3 byte ADS data
3-2 byte accelerometer data
The serial protocol adds start and stop bits to each byte, for a total of 310 bits that have to be sent.
115200 baud has bit time of 8.68uS per bit, so it takes 2.69mS to send all that data.
If you drop the accelerometer data, you still need 2.17mS to get it all out the door.
Oh, and no, when you press the reset button, it does NOT reset the RFduino. For that you need to reboot the board.
I've done some research on the streaming-transmission thing (8 ADS1299 Channels in 31 Bytes) and found the following:
a) the PIC32 Processor is sending exact every 4 ms. The transmission takes 3 ms, so 1 ms is left free.
b) the radios follow this timing with great jitter
c) some package frame will not have the 1ms left space between each other: they come without any space between
Sometimes the dongle-received frames have the starting 0xA0 and the ending 0XC0 on the wrong position in the frame.
This points for a software error in the dongle RFduino .
@biomurph: is this problem solved with new RFduino software?
Another RFduino error is that sometimes the connection fails between the two Radios.
As if something in the software would have an overflow after some time:
a) leave the dongle powered for some 10 min, having the 32Bit board unpowered
b) switch on the OpenBCI 32Bit board
c) the radios do not connect
Please verify this.
@biomurph: there is no need for 20 Rx-buffers I think. Debugging realtime software should be done with professional tools
or you need a lot of experiance. To use the toolchain from nordic semiconductor, to be able to set breakpoints and to look at the state-machine in the software.
I've bricked my bootloarder by try programming the 32Bit board with low batteries. The MPIDE is not the problem I think.
So I try to program the bootloarder with PICit3, but there is no tutorial how to do it.
But you have to do this in production?
To have a tutorial for this would be fine, because it is difficult to read all the stuff of this thread each time,
and there are things written that are no longer valid.
When the PIC32 sends serial data to the RFduino, it does not take 3mS. The serial transmission does take ~2.7mS to complete, but inside the PIC, the program just puts the data (31 bytes) into the output buffer (64 bytes), so there is much more than 1mS available for the PIC between samples.
The radio packets do come in at odd times, but that is not important, because the samples were gathered at the 4mS rate.
I will try your connection error problem. When you reset the Dongle, does this solve the problem?
We do need to have the very large RX and TX buffers on the radios, because we are using them to upload code to the PIC32 over air. the avrdude that the chipKIT folks made uploads the program file in 256 byte pages. We need to handle abit more than that to get the program uploaded.
I'm sorry to hear you bricked your bootloader. I will get a tutorial up soon. For now, please connect the picKit3 thusly:
All the bootloading pins are broken out on the OpenBCI 32bit Board.
I tried to to update the firmware on my 32bit board and now no blue light on power on. I followed the instruction for using the arduino ide. It would start uploading then program flash failed. I tried many times and then after reading this thread and applying my limited understanding to all this decided to update the radio host firmware on the dongle. I succeeded, at least it said success, and then I went back to update the board firmware.
At first it kept saying target not found but after many attempts it started uploading and then flash failed again. I tried again and back to target not found and then after many more tries back to uploading again with flash failure and then twice I got all the way through the upload but with an error at address 1D00125C: file=FFFFFFFF, mem=01000301 on verify.
Any assistance in getting my board up and running again will be much appreciated.
So I take it that the ftdi friend indeed does come with the headers already soldered on?
Also, if I use the ftdi friend, do I still have to use the breadboard to connect the jumpers to the openbci board or is the breadboard only necessary when using a capacitor?
I have successfully uploaded the latest rfduino firmware onto both the dongle and board.
I now get through the upload process every time but get the same address error on verify. I have tried a dozen times and followed advice on other thread about using new batteries, holding board close to device, and timing the reset button.
What next?
EDIT: Reread thread, tried superstition trick and made it almost through verification but with a read page error. The board blue light however now turns on so I will attempt to use device and see what happens.
Got the verification read page error, device now powers on and seems to work fine. If the code didnt upload properly would there be any symptoms or would the device simply not power on?
@nk If by chance you do not go through all the numerous functions you might ignore that some are corrupted. All that I can do is to sympathize because I currently live the same nightmare...
@biomurph That we have to keep close, less than a centimeter , host and device, let think that RFduinos do not work well. Should we change them? Is it possible by hand? Have you tried?
If the verification failed, but it still turns on the blue LED and responds to the GUI, it's likely that there was just a radio crash during verification. We have found that if it is really not working, it just doesn't work.
I guess it could possibly be the RFduino. Those solder connections are not hard to work with. I imaging that you could use solder braid to remove it, or use a hot-air re-work tool for sure. We have not had any issues with any of our RFduinos. They are shockingly reliable. Have you tried to upload in different locations?
I think it worth sharing that when I try to upload a code to my 32-bit board, but I encountered an error, where the Arduino cannot locate the library. But that confused me for a little bit, because I've been using Arduino to upload codes to 32-bit board with no problem before.
I thought the problem is coming from using Windows. So, I tried it in my Mac, but I encounter the same error. Long story short, I found the problem coming from using the latest Arduino version (1.6.6).
The solution is using any previous version of Arduino; to be very specific ( from 1.5.8 BETA to 1.6.5).
It could be that the library of OpenBCI needs to be updated to work with version 1.6.6, but I'm not sure.
I also had to use an earlier Arduino version last week uploading code--I think I ended up using 1.5.4, arbitrarily. The problem was the compiler not finding the library (despite the application recognizing it).
Hi every one , i faced a problem in firmware uploading of open BCI 32 bit v3 board... I download all the firmware and libraries and also installed the chipkit core for arduino latest version ... but when i verify the code it gives me this error : pic32-g++: C:\Users\Adeel\AppData\Local\Temp\build72b065f92d2b6e4f5d8477e3c9f59c39.tmp/core\core.a: No such file or directory
Can any one please help me... yur support will be appriciated.. thanks
@adeel, hi. I merged your uploading question into this existing thread with uploading suggestions. Are you using the 1.6.5 IDE? Here are some related posts that showed up with a search,
@wjcroft Thanks Alot .. its realy helping and ables me to find the solution for this problem .... the main problem is that latest chip-kit cores are not compatible with arduino 1.6.7 and AVR boards 1.6.9 ... for this I downgrade my arduino IDE to arduino 1.6.5-R5 ... and from boards manager install arduino AVR 1.6.8 only ... this helps me alot and thank you again for your support
Comments
If by chance you do not go through all the numerous functions you might ignore that some are corrupted.
All that I can do is to sympathize because I currently live the same nightmare...
@biomurph
That we have to keep close, less than a centimeter , host and device, let think that RFduinos do not work well.
Should we change them?
Is it possible by hand?
Have you tried?
Thank you,
Yannick.
i faced a problem in firmware uploading of open BCI
32 bit v3 board... I download all the firmware and libraries and also
installed the chipkit core for arduino latest version ... but when i
verify the code it gives me this error : pic32-g++: C:\Users\Adeel\AppData\Local\Temp\build72b065f92d2b6e4f5d8477e3c9f59c39.tmp/core\core.a: No such file or directory
Can any one please help me... yur support will be appriciated.. thanks
https://github.com/arduino/Arduino/issues/4055
https://github.com/arduino/arduino-builder/issues/42
https://forum.arduino.cc/index.php?topic=359049.0