Categories

RoseOnRails – code

Hi.

This weekend, I continued the Python tutorial and reviewed what I had already learned. We’re all going to badly need Python for the intelligence part of the game.

I also carried out some tests with the code of the central station, since I felt there was a considerable latency in the characteristics being written through my code compared to when I wrote them directly with gatttool. I activated all DEBUG print options in BlueLib and tried to dive as deep as I could in the sources of BlueLib and BlueZ to figure out what was responsible for that latency. Well, (fortunately!!) it was simply due to the fact that I “got primary services” and “got characteristics” each time a user wanted to write a value to a charactertistic of the train. But since we already know the (only) service and the (few) charactersitics that we use, it’s wiser to just stock them in an array at the beginning of the code (when I connect to all of the trains and start the notification) and then simply use the struct that I have stocked in this array to write to the desired characteristc. It’s way faster now! Ouf!

On Sunday, Yann and I started thinking about how to structure the intelligence of the game. But first, we had to determine how, precisely, we were going to detect the position of our locomotive with the magnets on the circuit and believe me, it was much less obvious that we thought! In fact, given that we had seen on Friday that the Hall sensors we currently use, detected only the South pole, we woud have a problem to encode ones and zeroes according to North or South… more simply put, there is South or nothing for the Hall sensor switch we use, so we can’t do any encoding based on the pole of the magnet, as we had thought we could do.

In short, we thought of using a combination of a Hall switch (the one I described above) and a Hall latch (which detects the North pole too). However, there’s still a problem since we won’t know if we have ran over one or N North poles (becuase the switch simply doesn’t detect North and the latch does detect it but it changes state the first time it sees an N after having seen S, and that’s it, it’ll stay to N as long as there’s no S). So, we simply had to do a type of encoding that flipped one bit each time, I mean encodings of type NSNS or SNSN, or SSS, etc. in short no code with two or more consecutive Ns… However, we’re still not fully certain, we have to discuss with Alexis & Sam about it, which I guess we will do today.

As mentioned above, we then started to think about the intelligence itself and how we would implement it in Python (what classes, attributes, modules, how many threads, what type of security for simultaneous access to the shared arrays of LEDs and turnout, etc.). We already have an idea that Yann started to implement last night, however, I won’t describe it here now. I will do so when we will have talked about it to the other members of the group and will agree on the architecture.

Last night, I changed again some things on the code of the central station (added some metadata to the notification in order to know which train notified, parsed commands in Python in order not to have to type MAC address each time but rather the number of the train, etc.).

Hopefully, we will soon have the PCBs with the components soldered and will be able to implement all these codes “for real” and see what happens!

Stay tuned 🙂

 

RoseOnRails – ble and ledstrip on stm32f103

Hello all.

Today, I worked on the application I had started to code yesterday (the server app that listens for incoming connections from users, creates sockets to serve their commands, and (dis)connects and write to BLE devices characteristics upon request of users). I implemented the writing part, tested on different machines, and with several boards.It worked fine.

Then I started to code the thread responsible for receving notifications from the devices. The thing is that by doing fork() I could handle several connections with BlueLib (since forking makes two separate processes and not threads, so the memory is not shared). However, by creating threads, I had a BlueLib error telling me that a I couldn’t establish more than two connections (if I got it well, it’s because threads share the same memory and BlueLib contains global variables that are therefore common to all threads (furthermore, BlueLib itself deals with 2 threads..!) so in short, it’s not possible to have two connections since the two threads would have to share the same memory resources). Yann suggested we could do several fork()s, so several processes, to deal with the multislave connection. But since we saw Hubert in the afternoon we decided to talk directly to him about it. He explained how BlueLib worked to us and how we should do to implement the multisalve functionality… but it seemed “a bit” difficult to implement staright away. So he said he would have a look at it and do some improvements and let us know about what he’ll have done. I guess I’ll try the fork() just to see if it works, but I’ll ask Sam’s advice before… I’ll see this tomorrow.

Then I started working with a stm32f103cb (the board ROSE students used last year) since we’ll be using a stm32f103re processor (and not a stm32f407 anymore). I spent quite a long time re-configuring the SPI on it and doing the right connections… fortunately, I managed to light up the leds once again. Then I tried to assemble several led strips (10 on one SPI) to see if we had enough power (and memory for the buffer stocking the bits to send through SPI) to control them all.

Unfortuntely, it was fine up tp 8 ribbons (of 30 LEDs) but then I started to have ram overflow errors. Checking the datasheets, I figured out that we might have some memroy problems since the buffer will become too big with 30 ribbons of 30 LEDs each to control. I’m not sure yet, maybe I did the calcualtions wrong since I’m a bit tried right now, but I’m really worried about this and I guess first thing I’ll do tomorrow is to think about it and determine if yes or no we will have enough memory for our buffer…

That’s about it for now. See you soon!