ruppie Posted July 15, 2020 Posted July 15, 2020 (edited) What about an electronic system that is fully (in wide areas) flexible to fullfill a huge number of requirements but most impoirtant: "It is fully compatible with all (at least Technic Hub) HUB's and the LEGO applications used ? The Idea behind: 1. The LEGO wireless protocoll has been published 2. . Some nice guy have bublished some usefull Technical details about LEGO Serial Protocoll. The only thing we have to do, as with the plastic bricks: We have to put them together. I will start , the picture in Link_ Proof of Concept: powerded Up compatible HUB System (ome kind of digital twin) It consists of: a) Microcontroller board provided by a framework to make it possible to build an BLE perihereal that is able to connect to actual LEGO powered up / and or control+ apps --> A dual role mode is possible by means of atype of recorder that reads and stores "Programs" end in realtime and write them to other LEGO hubs later on by using its orn file system. --> May be updated with dispkay or interfaces by means of web servers..... b) Because controller boards shown do have only one serial port to communicate with powered up serial interface, a serial interface multiplexer is used c) A Number of Motor driver oard, according to available power and driver pins of the board d) a number of step down converters if main power supply is choosen with respect of requirements of Motor and motor drivers. Inspired by the work of philo :https://www.philohome.com/wedo2reverse/protocol.htm And the work of GianCann; I began my my development of my own HUB a while ago: At first i choose Arduino 33 BLE Board because it accepts a whide range of supply voltage , without need to use DC step down converters in case of usage of higer voltage Power supplies for the motor drivers. Due to so,e issues about ArduinoBLR Lib acccording to advertising and Scan response data , i continued testing based on ESP32 Controller: As an important milestone i was able to connect to "powered up" app as well as control+ app, even it is only a simple connection test without any event handler for data exchange, /* Based on Neil Kolban example for IDF: https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLE%20Tests/SampleServer.cpp Ported to Arduino ESP32 by Evandro Copercini updates by chegewara */ #include <Arduino.h> #include <BLEDevice.h> #include <BLEUtils.h> #include <BLEServer.h> // See the following for generating UUIDs: // https://www.uuidgenerator.net/ #define SERVICE_UUID "00001623-1212-EFDE-1623-785FEABCD123" #define CHARACTERISTIC_UUID "00001624-1212-EFDE-1623-785FEABCD123" BLEAdvertisementData oAdvertisementData = BLEAdvertisementData(); BLEAdvertisementData oScanResponseData = BLEAdvertisementData(); const char advLEGO[] = {0x02,0x01,0x06,0x11,0x07,0x23,0xD1,0xBC,0xEA,0x5F,0x78,0x23,0x16,0xDE,0xEF, 0x12,0x12,0x23,0x16,0x00,0x00,0x09,0xFF,0x97,0x03,0x00,0x80,0x06,0x00,0x61,0x00}; const char ArrManufacturerData[8] = {0x97,0x03,0x00,0x80,0x06,0x00,0x41,0x00}; std::string ManufacturerData(ArrManufacturerData ,sizeof(ArrManufacturerData)); const char ArrScanRsponseData[] = {0x05,0x12,0x10,0x00,0x20,0x00,0x02,0x0a,0x00,0x0c,0x09,0x54,0x65,0x63,0x68,0x6e,0x69,0x63,0x20,0x48,0x75,0x62}; std::string ScanResponseData(ArrScanRsponseData ,sizeof(ArrScanRsponseData)); // Set your new MAC Address uint8_t newMACAddress[] = {0x90, 0x84, 0x2B, 0x4A, 0x3A, 0x0A}; void setup() { Serial.begin(115200); Serial.println("Starting BLE work!"); //esp_base_mac_addr_set(&newMACAddress[0]); BLEDevice::init("Technic Hub"); BLEServer *pServer = BLEDevice::createServer(); BLEService *pService = pServer->createService(SERVICE_UUID); BLECharacteristic *pCharacteristic = pService->createCharacteristic( CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_WRITE ); pCharacteristic->setValue("Hello World says Neil"); pService->start(); // BLEAdvertising *pAdvertising = pServer->getAdvertising(); // this still is working for backward compatibility BLEAdvertising *pAdvertising = BLEDevice::getAdvertising(); pAdvertising->addServiceUUID(SERVICE_UUID); pAdvertising->setScanResponse(true); oAdvertisementData.setShortName("Lego Hub"); //oAdvertisementData.setManufacturerData(ManufacturerData); //oAdvertisementData.addData(advLEGO); //pAdvertising->setAdvertisementData(oAdvertisementData); oScanResponseData.setManufacturerData(ManufacturerData); oScanResponseData.addData(ScanResponseData); pAdvertising->setScanResponseData(oScanResponseData); pAdvertising->setMinPreferred(0x06); // functions that help with iPhone connections issue pAdvertising->setMinPreferred(0x12); BLEDevice::startAdvertising(); Serial.println("Characteristic defined! Now you can read it in your phone!"); } void loop() { // put your main code here, to run repeatedly: delay(2000); } In the future i will test with Adafruit Feather express , and play arround with other frameworks like mbed. In addition Adafruit Package can be used on Arduino BLE 33 if usefill. More interesting: All Boards shown, excpecially ESP32 supports internal storage and Microphyton --> Maybe intersting for the Phybrick Community ?!. I got currently a litle bit stuck by implementing the serial protocoll, but i think we have usefull technical base to play with. We can use; --> LEGO App with, oriinal powered up equipment , as well as a wide range of other types of motor drivers, motors and sensors, Just my ideas as starting point wouzld be nice to share with yours ;-) One disadvantage of new Technic Hub is the low power of the ports: You can no keep software compatibility, with only few compromises .If you like you can use even motor drivers like shown here: https://www.pololu.com/category/11/brushed-dc-motor-drivers Would be nice sharing your ideas about it, have fun, feel free, and happy building Marc Edited July 15, 2020 by ruppie Quote
GianCann Posted July 16, 2020 Posted July 16, 2020 7 hours ago, ruppie said: Would be nice sharing your ideas about it, have fun, feel free, and happy building Hi @ruppie (I have read your PM, but I'm in vacation and I'm not so reactive to reply). I understand what you want to do, but I don't understand the need since there is already hardware designed in the smallest details and, above all, with a very small dimensions. What is the advantage that a different hardware could offer? Especially now that there is an alternative firmware for the original LEGO HW that can easily extend the entire Powered Up ecosystem? Obviously I will provide you all my (little) knowledge accumulated in these months, but I don't find your project very stimulating. The advice, however, is to study the LEGO hardware and the Pybricks firmware to make the most of this combination. Tell me more why you want to make new hardware compatible with LWP (as a BLE server device) that is useful beyond the simple "I did this" Note: I don't know what your skill is in developing on embedded systems. I can only tell you that, by studying the Pybricks sources every day (to try to learn something new), what you want to achieve is very, very complex. Quote
ruppie Posted July 16, 2020 Author Posted July 16, 2020 (edited) what you want to achieve is very, very complex. No its not, because i have proven befor that archiving and building a remote control can be very simple. Most important: AWhenever possible i follow the "Do one Thing path". My gprimary goal is not to fullfill every possible requirement some one may have. Marc but I don't understand the need since there is already hardware designed in the smallest details and, above all, with a very small dimensions. The idea behind is very simply: Just as an interesting task for a non comercial hobby ;-) There are plenty of people not satisfied with original technical base: -> lack of power -> Current protection switches off drives very easily -> Missing rogramm / custom space, sd card... Or with the word of others: The missed some kind of "man in the middle" . Assume that the ESP32 simple act as some kind of communication endpoint for the LEGO App , for different solutions. Not ecessarily to replace given LEHO Hubs, more as an alternative / addition path. For that reason , for makers, for builders, hobiiest like me, it would be nice if it is possible to build an alternative based on given parts , like LEGO The intention is neither two create a PCB or complete new design, build up a product that can be sold. The question is: How to use all availabe (and affordable) parts and put them together to build an alternative . Example: I while ago i a have build my own Remote control for the lego topgear car.: https://fritzing.org/projects/ble-remote-control-for-lego-topgear-rally-car now i would like to use Control+ App profile with my "Own Hub" At least as hobby task and to learn something ;interesting-) Marc Edited July 16, 2020 by ruppie Quote
GianCann Posted July 16, 2020 Posted July 16, 2020 57 minutes ago, ruppie said: At least as hobby task and to learn something ;interesting-) Ok, this is very comprensible. However, the Bluetooth communication part is probably the easiest thing to implement. The "big" problem is managing the UART protocol simultaneously on multiple ports, as well as the more complex management of individual motors/sensors. In any case, if I can help you I am here ;) Quote
GianCann Posted July 16, 2020 Posted July 16, 2020 In this moment I am on the beach without my PC so I can't send the code of my simple "color sensor reader"... in the meantime I try to reply to your question (send via PM) about the LEGO UART protocol: 1 hour ago, ruppie said: Question is if i can take a look at your code , expecially what is the trick within the serial communication to sucessfully switch over from Init mode to measuremode of the sensors. After that the sensor has sent his "presentation data", the hub reply with an ACK byte, close the communication at 2400 bps and reopen the channel to maximum speed trasmission declared by the sensor in the presentation data. From this point and beyond, the sensor start to send his data for each value change and each time the hub required this wich a 0x02 byte (SYNC) (if I remember well, every 100ms). The sensor/motore can have several "working mode" (listed in the presentation data) and the hub can switch to another mode sending a specific message to sensor/motor. I forked the technical-info from Pybricks project, adding some other info (I also made a pull request to merge with the original source): https://github.com/GianCann/technical-info/blob/master/uart-protocol.md Take a look here, and if you have any question, ask without problem ;) Quote
GianCann Posted July 16, 2020 Posted July 16, 2020 Other useful source of information: https://github.com/JorgePe/BOOSTreveng and https://ofalcao.pt/blog/series/sniffing-the-lego-interactive-motor (the entire blog of @MajorAlvega is a interesting source for LEGO and electronics fan) Quote
ruppie Posted July 16, 2020 Author Posted July 16, 2020 8 hours ago, GianCann said: Ok, this is very comprensible. However, the Bluetooth communication part is probably the easiest thing to implement. The "big" problem is managing the UART protocol simultaneously on multiple ports, as well as the more complex management of individual motors/sensors. In any case, if I can help you I am here ;) Hi, my problem is not to understand the basic concept, how it should work. ;-) I habe to rewiew my code , i think i have a timing problem somewhere in the state machine - To shorten this a litle bit i asked for the simple example as reference, but enjoy your holiday fisrt i am not in ahurry about it . The other thing is;: if i am right the original LEGO HUB is based on STM32F....- So, depending of the version, and other peripjeral you use you can usally use a number of serial peripherals in pareallel. By using a RTOS Midleware and make usa of UART Interupt handlers, i don't think that it is abig issue ,as i can remember from my STM32 projects ~10 Years ago. Because i just switched from Arduino BLE 33 Nano to ESP32 i will take the chance to rewrite my code and rewiev the resources you send. Simply leave me when back from vacation. Quote
Mr Hobbles Posted July 16, 2020 Posted July 16, 2020 This is very cool! I wonder if you can get the PUP handset/remote to connect to your custom hub directly? :) Quote
GianCann Posted July 16, 2020 Posted July 16, 2020 (edited) I think it's possible to do @Mr Hobbles Edited July 16, 2020 by GianCann Quote
ruppie Posted July 17, 2020 Author Posted July 17, 2020 (edited) 10 hours ago, Mr Hobbles said: This is very cool! I wonder if you can get the PUP handset/remote to connect to your custom hub directly? :) Basically its all about the advertised BLE Service and Characteristics. Longer answer is: : It depends on the expected profiles (question and answer sequence) after connect that is espected by the handset or the apps. As dscribd in the LEGO wireless documentation, all PU devices curently use same service and only one same characteristcs .In the past the problem was about the handshaking sequence after connection, for example older versions of the control+ app won't run if read connection profile, read by port info commands was not as expected, Best practice is to follow handshake and opperation send and receive BLE sequences by using a BLE sniffer. There is a good description on how do do this with wirehsark n the nordic homepage. Note: I had fifficulties with the bLE plugin by using wirehsark versions newer than 3.0.7 ;-) Example:Control+ app: By using older versions, connection processes never finished because software always reconects and restarted handshaking seuence if not found port tinformations as expected for a specific profile, by means that nothing or wrong type of motor / sensor has been connected : By using newer versions , the connection and handshaking seuence is always finished , displaing expected conection diagram .For same reason the handsets for train hub did not connect with Technic Hub , or did not allow, any type of Motor. But this was more an issues about "custom build profiles" and product bindings .A type of tight restrictions to force strong product bindings due to marketing reasons , i guess.. When you do customisings on your own you must focus only on the basics :I would like to point you again to my Remote control solution:https://fritzing.org/projects/ble-remote-control-for-lego-topgear-rally-car This will work with ESP32 as HUB , too. It is a very lean design in Hardware and software because it is only designed and made for a single use case "Controlling car with specfic, well known requirements.. For that reason there was no need to investigate the ports before. Or in short words: What would be the advantage do do so . Or what would be the worst case if ...? I have answered both questions with : "Nothing", because i am in control about all and the only "end user".For that reason i can keep my designs simple ;-) Basically you can always follow two basics path_ 1. Try to stay as open as possible, this will make the hardware and even more, the software very complex, because you have two think about plenty conditions and use cases. 2, Try to follow the "do one thing" ore clean code design path: You focus on a well designed path, at least you will provice several versions or variations of your firmware to provice different use cases, Edited July 17, 2020 by ruppie Quote
GianCann Posted July 17, 2020 Posted July 17, 2020 2 hours ago, ruppie said: Best practice is to follow handshake and opperation send and receive BLE sequences by using a BLE sniffer. In the first post you have declared that you haved successfull connect the Powered Up App with your "custom" HUB that emulate BLE profile of a smart hub. In theory, at this point, you can connect also a PU Remote Control. Don't care the fact that Control+ App don't connect (or better, don't work) it they don't find a specific configuration on device's port. Do you have a remote control to make a simple test? Quote
GianCann Posted July 17, 2020 Posted July 17, 2020 I had a few minutes to work with the PC. This is the first series of message sent form the LEGO app to the "Fake HUB" (I used an ESP32 ATOM Matrix from M5Stack) Note: I have removed from the output the first two bytes (message lenght and Hub ID) of the Common Message Header. So, the leght of the entire message received on BLE characteristic is specified in "Rcv x bytes", and I report only the useful information 10:25:49.997 -> Starting BLE work! 10:25:50.646 -> Characteristic defined! Now you can read it in your phone! 10:25:59.626 -> Device connected 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x2(�) 0x1(�) 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x2(�) 0x3(�) 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x4(�) 0x1(�) 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x4(�) 0x3(�) 10:26:00.373 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x1(�) 0x1(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x1(�) 0x3(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x3(�) 0x1(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x3(�) 0x3(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x4(�) 0x5(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x3(�) 0x5(�) 10:26:00.440 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x9( ) 0x5(�) 10:26:00.440 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x8(�) 0x5(�) 10:26:00.474 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x7(�) 0x5(�) 10:26:00.474 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0xA(�) 0x5(�) 10:26:00.474 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0xD( ) 0x5(�) 10:26:00.508 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x2(�) 0x2(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x2(�) 0x5(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x5(�) 0x2(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x5(�) 0x5(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x6(�) 0x2(�) 10:26:00.574 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x6(�) 0x5(�) 10:26:00.574 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x1(�) 0x2(�) 10:26:00.574 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x1(�) 0x5(�) After this series of command, I tried to "change" the name of the HUB (only to send command, of course) with the text LEGO 10:26:20.523 -> Rcv 9 bytes : MSG_TYPE=0x1 PAYLOAD=0x1() 0x1() 0x4C(L) 0x45(E) 0x47(G) 0x4F(O) So, the communication between the App and the fake HUB works. I also tried to simulate the sending of a simple motor drive command but this I have not received. Probably it is necessary to respond first to the various commands that the App has sent (the first are for the subscription of some alerts). Quote
GianCann Posted July 17, 2020 Posted July 17, 2020 Ok, this is what the App ask to the Hub: Request the actual status and subscribe notification for these alerts (0x03 > MSG_TYPE Hub Alters): 0x02 High Current 0x04 Over Power Condition 0x01 Low Voltage 0x03 Low Signal Strength After this, the App request info about these Hub properties (0x01 > MSG_TYPE Hub Properties): 0x04 HW Version 0x03 FW Version 0x09 Radio FW Version 0x08 Manufacturer Name 0x07 Battery Type 0x0A LWP Version 0x0D Primary MAC Address And request value/subscribe notification for these other properties: 0x02 Button State 0x05 RSSI 0x06 Battery Voltage 0x01 Advertising Name So, the "fake HUB", at least have to respond to these information. Quote
GianCann Posted July 17, 2020 Posted July 17, 2020 (edited) This is the complete initial handshake from Hub <-> App. (I have used a City Hub to make some test, updated with the last LEGO firmware) Note: values are in decimal When the BLE connection is done between the devices, the hub send this data to the other device (app or remote control): (in red: common header + message type, in black: payload) Hub > (5 0 4 0 0) > Hub Attached I/O (Port 0, Detach I/O)Hub > (5 0 4 1 0) > Hub Attached I/O (Port 0, Detach I/O)Hub > (15 0 4 50 1 23 0 0 0 0 16 0 0 0 16) > Hub Attached I/O (Port 50, Attached I/O, TypeID 23 = Hub Light)Hub > (15 0 4 59 1 21 0 2 0 0 0 2 0 0 0) > Hub Attached I/O (Port 59, Attached I/O, TypeID 21 = Battery Current)Hub > (15 0 4 60 1 20 0 2 0 0 0 2 0 0 0) > Hub Attached I/O (Port 60, Attached I/O, TypeID 20 = Battery Voltage) Now, the LEGO App send these informations request, obtaining relative replies from the hub: (in red: common header + message type + operation type [alway 0x06: Update-upstream], in black: payload) App > get HW Version: Hub > (9 0 1 4 6 0 0 0 1) > to be decoded... App > get FW Version: Hub > (9 0 1 3 6 0 0 2 17) > to be decoded... App > get Radio Version: Hub > (12 0 1 9 6 50 95 48 50 95 48 49) > 2_02_01 (is as string???) App > get Manufaturer Name: Hub > (20 0 1 8 6 76 69 71 79 32 83 121 115 116 101 109 32 65 47 83) > LEGO System A/S App > get Battery Type: Hub > (6 0 1 7 6 0) > Normal battery type App > get LWP Version: Hub > (7 0 1 10 6 0 3) > LWP 3.0 App > get Primary Mac: Hub > (11 0 1 13 6 144 132 43 12 12 18) > 90:84:2B:0C:0C:12 And finally, the LEGO App send these informations request, subscribing for further notification of values changes App > get & subscribe Button State: Hub > (6 0 1 2 6 0) > Button state = False App > get & subscribe RSSI: Hub > (6 0 1 5 6 0) > RSSI = 0 (Maximum level) App > get & subscribe Battery Voltage: Hub > (6 0 1 6 6 100) > Battery at 100% (note: I have used fresh battery!) App > get & subscribe Adv. Name: Hub > (14 0 1 1 6 83 109 97 114 116 32 72 117 98) > Smart Hub So, @ruppie, now you have a new piece to step forward Edited July 17, 2020 by GianCann Quote
ruppie Posted July 17, 2020 Author Posted July 17, 2020 (edited) 29 minutes ago, GianCann said: So, @ruppie, now you have a new piece to step forward Unfortunately you haved mixed up some issues and people ?! I was the guy asked you for looking/ review at your ESP example Code about color sensor and serial protocol before i will ask additional questons , because the therotical concept is quite clear. But i wan't to have something for code compare to identify where i have made the mistake , never mind . The guy that ask something about the bluetooth laver was"Mr Hobbles" i guess But thanks again for your time you have spent in your holiday ;-) Marc Edited July 17, 2020 by ruppie Quote
Mr Hobbles Posted July 17, 2020 Posted July 17, 2020 Yep, I think there's some confusion. :) Perhaps I wasn't clear about the remote to begin with. My comments about the remote are more because while I'm aware it does advertise the same BLE services and characteristics as other hubs, even using the same LWP protocol for advertising its buttons as internally attached devices, it doesn't appear to work the same way when connecting to other hubs. There appears to be a bonding process used to pair the two together. In addition, my efforts in sniffing the packets when a remote and hub are connected together have been fruitless when using the BTLE profile in Wireshark, which leads me to suspect it might not be BLE at all? I believe all Powered Up devices use some variation of Nordic chipsets for their BLE capabilities, which are capable of a custom protocol called Nordic ESB (Enhanced Shockburst). I've seen this used in other products where both sides use a Nordic chipset, so they negotiate a change to use ESB instead of BLE. https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/intro-to-shockburstenhanced-shockburst I could be wrong about the ESB part and just be sniffing the connection wrong though. :) Quote
ruppie Posted July 17, 2020 Author Posted July 17, 2020 @ Mr Hobbes: please have a look nte the beginning of the "Tear down post" . If iam right they don't use a nordic BLE device ?! Unfortunately i don't have a LEGO Trainhandset to test on my side, but according to the expereinces i made with the Mouldking Remote conrol, i was not able to sniff traffic about it to , so far. Sometimes it us strange. My expereinces are all about the Technic HUB, my own build remote control (adafruit nrf52840 express) ESP32 and LEGO app only. Quote
GianCann Posted July 17, 2020 Posted July 17, 2020 No confusion guys... I've only added some information to the discussion. Yes, @ruppie... Later I publish the code to manage the color sensor from a hardware other than the smart hub. @Mr HobblesHobbles I think the remote control can work both as a peripheral and a central role (in the LWP documentation we talk about this type of device). Now that I have an idea (and a basic project) of how to emulate a Smart Hub, I will try to see if I can also connect Remote Control. I'm still on vacation for a couple of days, and I haven't brought all the material to "play" with me: I really miss the Remote Controller! Quote
ruppie Posted July 17, 2020 Author Posted July 17, 2020 (edited) On 7/16/2020 at 8:39 AM, GianCann said: but I don't find your project very stimulating. Most important: Because you are on your well deverved vacation, ou should relax and don't read computer message posts ;-) About: possibel product / project ideas;: As discussed with Werner (LOK24) today something that is missing so far, without the need designing new hardware is someting ke a "Man in the midle" . A device that can work as some type of recorder and player for powerd up "programms" hat are stored as json files as i was told by him. Why not using the "M5 Stack System" or even better this: https://www.hardkernel.com/shop/odroid-go/, to do so as starting point and developing base . A very usefull to establish the "Play " function may be the legoine lib of cornelius munz. Because we can connect now to the powered up ap we can then add some type of "record function " to stare the command stream on the sd card for later use, Marc Edited July 17, 2020 by ruppie Quote
Mr Hobbles Posted July 17, 2020 Posted July 17, 2020 22 minutes ago, ruppie said: @ Mr Hobbes: please have a look nte the beginning of the "Tear down post" . If iam right they don't use a nordic BLE device ?! Unfortunately i don't have a LEGO Trainhandset to test on my side, but according to the expereinces i made with the Mouldking Remote conrol, i was not able to sniff traffic about it to , so far. Sometimes it us strange. My expereinces are all about the Technic HUB, my own build remote control (adafruit nrf52840 express) ESP32 and LEGO app only. You're absolutely right, I missed that! Apparently it's TI - I don't know where I got it in my head it was Nordic. :) Not ESB then - just tricky to sniff! Quote
ruppie Posted July 18, 2020 Author Posted July 18, 2020 On 7/16/2020 at 8:39 AM, GianCann said: Hi @ruppie ......Idon't understand the need since there is already hardware designed in the smallest details and, above all, with a very small dimensions. ......what you want to achieve is very, very complex. @GianCann: : 2 small additions i forgot 1. since there is already hardware designed in the smallest details and, above all, with a very small dimensions. By following the "Tear down" thread it makes me wonder why they have made the decision two split Bluetooth and common tasks into two separate controllers . I expected something like the STM32WB familiy that has a very usefull dual core architecture. If iam right you have just started some basic investigations (see your github about STM32) ?! if you are interested have a look at this: https://midatronics.com/shop/development-boards/mkr-sharky-i/ or sharky . from my point of view they have a more usefull form factor compared to the https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/stm32-nucleo-expansion-boards/p-nucleo-wb55.html Besides the fact that i liked the old peripheral library more and did not have much expereince with CubeMX, it still is a good starting point expecially because of this https://www.st.com/en/embedded-software/x-cube-ble1.html . Because i don't know your developming environment for STM32 (KEIL ?) , but do you know that plattform.io supports Cubemx too, or that you can use Visual Studio witjh a extension "Visual GDB" - >https://visualgdb.com 2. what you want to achieve is very, very complex. : For that reason i alsways try to concentrate on the basics first and try. Besides that a strong advice from my side; Even if it looks complex and oversised : "Use an RTOS" , because of it makes it "easy" to spit your application in separate well designed tasks = do one thing and clean code idea, In addition splitting it up in separate tasks allows it having a system of components that are indepenent and for that reason the y can be tested in independent clean environments in case you got lost at some point: For that reason i will lay back for a while and studie some basics accroding to this book; https://www.elektor.de/freertos-for-esp32-arduino Just some ideas i wanted to share, because you have asked abaout my background and experiences Quote
JopieK Posted July 18, 2020 Posted July 18, 2020 I spot some featurism here ;) I think an RTOS is often a good idea but am not sure about simpler uC applications. I would like a good RTOS for Raspberry Pi though, would be great to use it as a main controller that does all the in-between stuff (probably with node-red at the highest system level?!). An RTOS for the Pi should be doable but one needs to recompile a whole lot and I had trouble running Debian and Ubuntu in a virtual machine on an USB device last time I tried. About those great things like dual core: With microcontrollers always remember that you should optimize: power, performance and e.g. peripherals, everything has its pro's and con's: there is no free lunch, if you want dual core, great but your application will consume more power etc. About the programming, it is indeed difficult to make software that is fully 'Uncle Bob proof' without an RTOS, on the other hand that is not always a problem, you can split systems in modules and a module is already a contained, loosely coupled entity of course, so only for your main control system you really need an RTOS I would say. E.g. for signals I use an Attiny uC, you can just give it a command over e.g. i2c. An RTOS would be a total overkill there. Even for the control post that controls maybe a few signals, it only has that task, controlling signals. I am working on a SAMD21-based controller turntable controller, for now I included a LoRa and nRF52 (actually XBee compatible header). Apart from that, for me the largest challenge is, what would be the best wireless protocol for controlling everything. I mean, both WiFi and BLE have their pro's and cons. The promise of BLE 4.2 / 5 being meshable sounded promising but I have not seen a great working proof of concept anywhere?! Quote
GianCann Posted July 18, 2020 Posted July 18, 2020 2 hours ago, ruppie said: For that reason i alsways try to concentrate on the basics first and try. Ok... but if you want to start from the "basic first" I think that first step is to explore the LWP implementation in the Hub. Your BLE code it's not complete and if you add PROPERTY_NOTIFY to the characteristics (as same in the original hub), the result is a crash of the LEGO App one moment after established the connection. If your project is based on the idea of emulation of a Technic Hub (with the opportunity to play with him trought LEGO App or remote control), the starting point is the investigation of the things that are new. 1) Control a LEGO Hub with LWP is a new thing? No... There are many, many example! 2) Control a PUP sensor/motor is a new thing? No... There are many example! 3) Act as LWP peripheral is a new thing?... Uhmmm! Yes... at least, in the past two year that I use deeply the PUP system, I don't have seen any project about this. Only your sketch of code (that not work when you go beyond the simple connection-established). So, from my point of view, before talk about hardware/RTOS/dual core and so much, I think that it's not so useful to go forward until you have explored THIS "basic first" point. The LWP compatible mode is the only and very "killer feature" of your idea. I think you are aware of it. Are you sure that this thing can really work? Quote
GianCann Posted July 18, 2020 Posted July 18, 2020 This is my code to try the emulation of a PUP Hub https://github.com/GianCann/ATS/tree/master/ESP32_LEGO With this code I get that the LEGO App connecting to my ESP32 and send some initial requests to the Hub... But there is a problem: The LEGO App crash with the NOTIFY property set to the characteristic. In you remove BLECharacteristic::PROPERTY_NOTIFY from the characteristic's constructor (line 93) the LEGO App works but it's not able to receive notification from the Hub (so, isn't useful). Quote
ruppie Posted July 18, 2020 Author Posted July 18, 2020 @GianCann: II think it depends of the timing wizhin the application: When to send which type of information, and do i have it only onetime or must it send until ... More important i think it depends on the correct contenty of the message. If i am right you have tried two send an; "Section 3.8. Hub Attached I/O Type Message": According two your message type code 0x04h ? It looks like an" HUB attached IO information message" with 15 bytes size. The possible mistake was the size of your array is 16 bytes. byte CharValue[]={0x0F, 0x00, 0x04, 0x00, 0x01, 0x26, 0x00,0x00,0x00,0x00,0x10,0x00,0x00,0x00,0x00,0x10}; LEGOCharacteristic.setValue(CharValue,15); In the end from my point of view the app crashes due to a possible unhandles exception due to wrong message format and / or contents i think ?! Will check if i have time ;-) Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.