-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLE/Wifi bridge #2
Comments
Hi @gavalierm - it sounds like an interesting approach to working with the cameras - being able to separate the data and send it out instead of interpreting and processing it on the ESP32 sounds possible. I think the Bluetooth connection would need to be maintained between the camera and the ESP32. I'm not familiar with passing connection handshakes, you probably know more about this than me. I have limited time to work on my own project, unfortunately, as I'm working on another project. However, I am happy to try and help. Working from my code base would be my preference (e.g. forked). Are you planning on making the new project a public repository? |
Hi @marklysze i m glad to hear that. Yes it can be public, why not. But in fact, i tried to find this approach on github but i found nothing. So it looks like nobody needs this or nobody got this idea :) and how nobody use this public issue to create own bussines :) Like i said i m not C programmer so i do not know how pointers work, why and how implement good and stable C code, if something works i do not know why really. Because i use Arduino when it came out i m stuck on Arduino IDE and "arduino thinking" attitude. But i see that do not using Arduino wrappers build above the ESP IDF API is better idea, but i do not know how. My project has simple idea (i sent to you a invitation to my private repo but i no think is still working.. 1yr old..) but need some better programmer.. The scenario is easy:
Phase B:
Phase C: All payloads are now forwarded and managed MQTT client and you can parse payloads waymore easy via javascript/python/whatever without compiling and flashing ESP again and again when logic needs update. And ofcourse you can build own PWA with better looking UI, you are not limited to BT range, ESP display/touch capability, because your ESP is now transef all data to the mqtt topics and you can sit on you laptop and control cameras over PWA in your browser using mqtt client. PWA mqtt client <-> mqtt broker server <-> mqtt client on ESP <-> bridge logic on esp <-> BT client on ESP <-> Camera Because ESP32-C3 and ESP32-S3 have BT/WIFI coexitence it can be done - but like i said i cant write clean ESP code which make sense and you it looks like you can. So i share this idea with you and hope you can do this (if you like the idea) |
Appreciate your detailed response and thoughts on an approach. I have just watched a short video on MQTT to try and understand it :). Sounds like it could work. I'm sure I'll have more questions to help establish feasibility. I'll ask a few, though I'll be honest that I'm a bit concerned that we can't both do the C++ programming, as there will be a bit involved and my time is, unfortunately, limited. However, let me ask a few more questions to see if we can make something:
If the goal is to take all of the camera specific code into a front end application that could work but from my experience to date, camera setting changes have to be very specific and having access to a number of different models would help. The physical cameras are needed for development. For example, I tried coding for on URSA Mini Pro G2 but the resolution changing wasn't working because I needed to knov whicm resolutions were full sensor and which were windowed - it wasn't as simple as just sending a resolution value to the camera. The issue with the BMD protocol is there is no reply to a packet sent so in doesn't tell you if something wrong. I just want to give this example because replicating what is being done in C++ in the front end will be required if it is handling all of the configuration. |
In fact MQTT is not the case (which i tried to use this time), it can be Websocket (which i use a lot), ESP-NOW (i never used because need another ESP-NOW - TCP/IP bridge to comunicate with other non-ESP devices). The BMD protocol you have mentioned in your readme.md https://documents.blackmagicdesign.com/DeveloperManuals/BlackmagicCameraControl.pdf Bluetooth messages is the same as SDI messages so example trigger autofocus on camera 4 SDI protocol is "broadcast" so every single device catch the data and parse "device bit" and if match with their own use data, but this means that every ESP need to know what device id represents and this means more logic into ESP and more handshaking between ESP and Node.js to declare device id. So easy way is do not wory about device_id in ESP - during MQTT handshaking determine the ESP_ID (this is constatn based on ESP mac addr, or cpu_id...) and use dynamic mapping in Node.js like "this cpu id = this SDI device ID". And this can be managed fawlessly in some PWA. So when you receive payload from BT is uint8_t *pData, size_t length, message which can be directly forward to the MQTT as "string" I send data from MQTT to BT with this part of code: Message was like [4,6,0,0,4,2,128,1,0x33,0x01,0,0]
and sendig message from BT to MQTT
And i plan write SDI protocol parser in javascript to use with for human needs... so when operator want to change isto to "400" i run mqtt.send('topic',encodeDataToSDIProtocol('iso',400)); //return payload message for BT and vice versa mqtt.reveive('topic',decodeDataToSDIProtocol(payload_from_bt)); //return human readable data like "iso/400" In recap:
|
And maybe i need to say that BT/WIFI coexistence was something that i can not trully tested. It works like expected but sometimes i just randomly get ESP to reboot. And because i wasnt 100 percent sure that code is OK and Healthy i can not say that RF coexistence is bad idea OR just my code is rubbish with memory leaks... |
Okay, I understand better what you're thinking. In the code base there's this class that handles incoming packets of data: So the ESP32 could send the bytes to the Websocket instead. Similarly, there's a function in: Called sendBytesToOutgoing that will send bytes to the camera, so this could be called when receiving data from the Websocket. It sounds like an interesting solution. If you can provide some sample code (whether it's yours or other code on GitHub) for ESP32 WiFi connect/maintain/disconnect, and ESP32 WebSocket then I can see how feasible it is to integrate into the code base. Then perhaps your repository could be the front end that accepts data and sends data back? |
Wifi on ESP32 in arudino wrapper is very straightforward. Still i will try to use MQTT not Websocket directly, and if this idea fails i rewrite it back to the websocket (which is more reasonable for bi-direct messaging) If i use websocket i need to extend "SDI" protocol to some new/custom payloads like "bluetooth handshaking" and "heartbeats messaging" or even "tally signaling with custom colors" i m not familiar how SDI protocol separate the CCU and TALLY or others messages. Here is my ino sketch for working ESP32 D1 mini tally light (based on websocket messages) - this is from my private repo
|
Thanks for sharing that. Due to my time limitations, I'd suggest you start on your side of things and when you have some working code I'll try and tie in with it by sending camera commands through to you (the byte data) and taking command data I receive from you and send to the camera. |
I can write some working code and add some notes like: There is some limitations what i m thinikg about:
|
Maybe the good way is add fake BOARD like "ESP_mqtt" to your code context and implement for this board only callbacks without display stuff, if your code have this scalability. And in main.c users define this board and will have access to the "mqtt bridge". |
Data Block have data set to the max value I m not sure thats 100 correct but i can update this when i found some mistakes. This is auto generated from the data sheet. https://github.com/gavalierm/blackmagic-camera-control-protocol
|
Yep, that's an idea - could add an MQTT specific board for platformio and in that main file could set parameters so that it uses MQTT instead of UI. |
When your side is somewhat functional and I have time I'll run it and see if I can do my side to send and receive commands. |
So i have some work done. Disclaimer: Because i do not know if i m doing it right i do my best :) What i choose:
What i have done:
Interesting part:
Whan i m missing and what frustrate me I think i was done BUT i realize that i can get any notification from CCU. I do not know WHY! because my subscribe is all the same as Timecode or CameraStatus. I tried to write to the camera but without results (but this is not the case now, it was only one attempt) I really missing something and i do not know what it is. |
You've done a bit! Would you be able to point me to the code you've written? |
I think i m fall in rabbit hole with Nimble ESP IDF. I think with basic Arduino BLE lib i will be done already....... I m struggling with basic i think in Nimble. My code is here https://github.com/gavalierm/btbm-tally and you have contributing rights, but because i rewrite whole code again and again becase testing and trying to get it done... maybe fork or branch will be good idea. It is one big file main.c with included gatt_client.c to split thing. Because i do not get things done i do not need to keep code clean for now. |
Hey @gavalierm, gotcha - this does sometimes take us down paths that we weren't expecting! I'll be honest that I'll find it hard to contribute to the repository because it's not in an environment I normally work in (VSCode and PlatformIO). If I do get some time to download it and load it I can see if I can get it going in VSCode/PlatformIO. If there's any way you can run VSCode and PlatformIO with it I'd be able to help more... |
I tried VScode many times, and still fallback to the my Sublime Text :) Maybe sometime that PlatformIO will e standalone app like aruduino IDE. Or even better, somebody integrate the platform io to the Sublime text. But meanwhile, ma code is done (all my headache) was described in the ESP-IDF issue. If you wan to try my code you can, maybe it will stay public forever maybe not. But you will still have access as contributor. Maybe you can help me check the syntex and resolve some "unprofessional" syntax? Like pointers, declarations or comparing and merging the data? |
You can try my code, it is working now. |
Cool, what device are you using? |
Hello,
in past i wrote private lib based on BlueMagic32 (but used only the connection part) to create bridge between BLE and Websocket.
My target was very simple, pass all data (including connection handshake) to the Websocket (or MQTT) and all app logic build on websocket server (node.js).
The main reason for this was better scaleability and future proof desing, becase no need to update ESP module every time when BMD protocol was changed, or something like that.
I was succesfull but the project died because lack of my time to optimize the workflow. (And i m not good on C++ or ESP).
I found this project and i like that is life and still receive new commits.
Goals:
Questions:
Do you like the idea?
It is possible to derivate your LIB to do all BLE stuff and coexist with Wifi stuff?
Thank you!
Underline:
Major problem was BLE/Wifi coexistence. ESP C3 was ok but not perfect, ESP S3 i bought but never tried, because no time. If BLE/WIFI can not be stable second idea was put two ESPs one for BLE, one for WIFI and share messages via Serial, or something like that.
The text was updated successfully, but these errors were encountered: