And congrats also to all ROSE teams, who have made an amazing work. It’s been a real pleasure to work with you.
I know… I should not post because ROSE is over. But drops have evolved since the last orals. And I thought you may be interested in our progress.
The three first picks you see are when our drop is sending advertising packets every 0.5 second. During advertising, our drop is idle. It means that our external flash is in ultradeep sleep mode, and so we have an average consumption of 65uA. Note that depending on advertising period, the consumption could be between 7uA (advertising every 10 seconds) and up to 1.13mA (every 20ms).
Then, the second range represents a connection period. Some peaks are bigger than others : it is when we read (or write) in our external flash. The average consumption when the drop is connected is around 190uA when we don’t access the external flash (but it is awake and ready).
The third range corresponds to a connection with our drop’s led on. At this moment, I indeed send a request to turn it on. When I saw how much it consumes (around 3mA), I was really happy that I turned it off a few days ago, and add a command if we really want to turn it on to identify to which drop we are connected. The led is turned off when I disconnect.
These information allow me to estimate our battery consumption. I was quite disappointed because it turns out to consume more than I expected (and calculated with the different datasheets I had). Especially for the memory. One access to the memory lasts 73ms when I was expecting 2ms… And because the consumption is around 5mA when we access to the flash… well… it is not so good.
Hopefully, I have not only bad news ! I have also worked on DFU (thanks to Drix). We are now able to flash a program thanks to DFU and the use of BLE (and NRF application). So now, when I want to update one of my drop, I don’t need a JLink probe anymore. I can send a signed command to my drop thanks to our control application (dropscanner) to launch DFU. Then, the drop waits until it has a new software. As soon as the drop receives the new program, it is launched.
A lot of work is still left to do. With our teachers, we thought of a new API, that could be used with other BLE devices (not only drops). I also thought of many other improvments such as adding encryption for signed commands because we don’t want that a hacker listening to all our transactions could replay them, etc !
Thank you for your support during ROSE. It has been a great experience. So amazing!
This is my last post on this Logbook (#nostalgy). It’s not going to be so long! Just a little message to say that I really appreciated ROSE and the great amount of things I learnt during this UE. Most of all, the way I learnt them was quite often “harsh” enough so that I’ll never forget them again (cf. remap registers… almost 2-3 days spent “debugging” an UART communication just because of this!).
True, there was a whole lot of work, a whole lot of stress, a lot of surprise also (as expected 😉 !). But on the whole it was an unforgettable experience of learning and having fun at the same time, with cool teachers and great classmates 🙂 !
Thank you all and hoping to see you soon some day again 😉
One little photo (just for le “swag”) :
This is the end, beautiful friend
This is the end, my only friend, the end
Of our elaborate plans, the end
Of everything that stands, the end
No safety or surprise, the end
I’ll never look into your eyes, again
Good night to everybody! 🙂
Even though I have not posted on the blog for quit along time, I have not been idle ….
Over the past few days, I have worked on several issues:
– tyding up the repository
Two days ago, our demo didn’t work because our locomotives didn’t receive any notifications.nommunication Even thought the notifications worked with gatttool, they didn’t work with our intelligence. While discussing with Alexis&Sam we supposed our problem came from bluelib. As we are the only group – and probably the only people in the world – using bluelib right now, we had no way of checking if this was truly the problem.
We have just discovered a bug in our code …. there is probably a problem in the communication between the TCP server written in C and the TCP client in python. The messages don’t seem to be well parsed.
As we still don’t know if the bug in our system comes from the parsing of messages in our TCP sockets or from bluelib. We are going to try and debug in parallel.
A whole lot of things have been happening lately.
After having (finally!) solved the UART “problem” as explained in my previous post, we were ready to test the intellligence module. While having done so, though, we found out that there were several bugs in the database and in the code. Therefore, the game, did not fully work as we expected! Furthemore, there were problems with the BLE communication, or more precisely, BlueLib, since we see that the commands are well sent through the TCP socket to the C server but not to the devices… so it can only be BlueLib…
Yesterday, we had to make a point to Alexis & Sam about our advancement and the current state of our project. Since the intelligence module still didn’t properly work and that we had random problems with BlueLib, we couldn’t have a proper demonstration unfortunately. But the imporant hting is that Sam & Alexis advised us to use noble (node.js module for BLE central applications) instead of BlueLib!
Stay tuned 🙂
Since last time, I have made a lot of things.
Then, I began a new app : Cache. It is the app for treasure hunt.
Because informations concerning the different hunts, and the clues have to be stored into the smartphone, I used SQLite to create two tables, one for the hunts, the other for the clues. I added methods to access the database, get all clues concerning one particular hunt, delete hunt/clue, etc…
In addition to that, I implement the whole behaviour of the app (the fact it has to connect automatically to all drops the app meets to know if there are some new hunts and notify the user if it is so, or check if the drop do not contains the next clue of a current hunt, etc…)
However, when we tested the app, there were some connection problems (connection to a drop was successful one time for ten attempts).
Moreover, I have not test all functions of the database.
I hope we will fix everything concerning this app tomorrow, to prepare a little hunt for you !
Our receiver almost works. We are able to receive the tension of our 3 coils :
But we still have a problem, our function that compute the maximum of 3 values doesn’t want to work …
I have one graph to show you. The audio codec is alive, and we will harness its power , just wait for it !
In blue we can see our raw signal. It no longer have discontinuities =)
On a side note, Noble seems a good option for Ble as 3 out of 4 group of us are using it. I’m glad it helped. I just hope it won’t burn.
Yesterday and today, I spent a lot of time trying to resolve the big mistery of the UART communication between our nRF51822 and our STM32f103RE. Yesterday, we found out that actually, there was still an error in our board.h file for the nRF regarding the TX pin, which we corrected. But this wasn’t the error… I checked also everything in the Makefile, switched to the new verison of chconf, mcuconf anf halconf files (just in case), and checked in the sources of ChibiOS and the reference manual of the STM32f103xE that we had the right configurations. But when checking if the program entered the interrupt handler (by putting a breakpoint then by toggling a pin’s state), we got that the answer was no. To make it short, the signal was received on the RX pin but didn’t seem to be interpreted by the STM32.
Today, Sam gave me some precious advice to try and find out the origin of the “problem”. we used different techniques to make sure the RX pin wasn’t read correctly: first we looked at the USART1’s SR register’s RXNE bit by writing a function that returned this value, the RXNE was 0 ! Then we “mirrroed” the state of the RX pin towards another one (i.e. we toggled its state accroding to that of RX), the result was as expected (we saw the right UART signal with the correct timing -> 26us for 38400 baud). So what wasn’t working? We checked the clock as well (STM32_PCLK2 as the datahseet specified)…. then, Yann pronounced the word “remap” and it made Sam almost jump!! Actually, what we had forgotten to do was to configure one bit (yes, just one *** bit) to mention that our AFIO (pin 7) had to be remapped to the USART1_RX register!!!! Now it works… no wonder! I’m actually rather happpy to have learnt it this way, I’ll never ever forget it again in my whole life…
On Saturday nigt, Glesion and I spent quite a certain time thinking about how to deal with the electromagnetic and magnetic noise of the motor distrubing the Hall effect sensor. After discussion, we found out that the debouncing method wasn’t a very good one, since the perturbation is, in our case, continuous (it happens all the time, before and after the detection of he magnet) whereas the debouncing is a method used usually when the perturabtion occurs after you the event is detected. We then thought about shielding the motor with a metal case but Alexis said it would be too costly and diffciult. We thought also about a low pass filter, but its implementation in software would require too much calculus and power consumption for our nRF51822. The other idea was a hardware low pass filter. But before this, when discussing with Alexis, he suggested we first put the sensor as far away from the motor as possible (in order to avoid that the magnetic field of the motor disturbs the sensro), and then, that we use a lower pullup resistance (this time, in order ot avoid the electromagnetic perturabtion). So we configured the pin as no pull and now use an external pullup resistance of 1.5kOhm (the internal oullup resistpr if the nRF51822 was much higher: 13kOhm). It still didn’t work as expected. So we finally, soldered a capacitor to have a hardware low pass filter and now it works as expected. Ouf! One less problem 🙂
What else?… Oh yes, after the LEDs worked, I completed the code of the central station to send commands to the ledstrip according to the encoding protocol that Yann defined (send <strip num>, then send <led num>, then <r>, <g>, <b>). In parallel, I wrote the Python function called from the Inteligence module to sned the 5 commands in one shot. The latter is still to be improved….
See you soon, gotta go make things work now… !