TinyCamML / Boron-and-OpenMV

This repo is continued progress between Boron and OpenMV as a self contained device that can successfully monitoring flooding on roadways.
MIT License
0 stars 0 forks source link

Add Boron firmware to enable cellular transmission and publishing #2

Closed BentleySettin closed 4 months ago

BentleySettin commented 5 months ago

@SUPScientist I added publishing code and will test it in the lab when I go back in next week, figured you may want to look at it too.

https://github.com/TinyCamML/Boron-and-OpenMV/blob/d570660cd345307e0bf74ff9e68ef27956a19899/PublishingCode

SUPScientist commented 5 months ago

Looks like the file is missing its type (suffix) again as Evan has previously noted. We should look at your git/hub workflow to try to nip this in the bud. Here are some pointers that might help: https://docs.github.com/en/desktop/making-changes-in-a-branch/pushing-changes-to-github-from-github-desktop. Please recommit/push with the .ino suffix. In fact, it would be much better to push the entire project folder so that you have all the lib and config files here also, so please drag the whole project folder into GitHub desktop for committing/pushing (assuming you're using GH desktop). Let me know when that's complete and I'll take a closer look.

SUPScientist commented 5 months ago

I added some comments to your .ino file with recommendations in https://github.com/TinyCamML/Boron-and-OpenMV/commit/3e9f44ababe1a75ce88f5301078db85598f61312. All comments start with //PJB: so you can find them easily. Some are critical, some are recommended.

BentleySettin commented 5 months ago

Thank you, I edited the repo to look more like the example. I will recommit the other ones similarly

SUPScientist commented 5 months ago

I'm going to keep being a stickler on this because I think file/project organization will make a HUGE difference in the next couple months and for the project's lifetime beyond this honors thesis...

This still isn't what I'd envisioned when I created that template. There are two problems with the Boron code.

image
  1. There shouldn't be two .ino files, only ever one in a given folder. How would someone know which to choose?!
  2. The .ino file should be organized within the full project that Particle workbench creates for you. That is, commit and push to github the entire folder that includes the lib and src folders, etc. See this screenshot for an example: image Having that full project folder in github is essential for sharing the configurations that you're using across the project (not just the lines of code in the .ino file that is currently shared).
BentleySettin commented 5 months ago

Thank you for being detailed with this! I need and desire the criticism.

I am trying to drag the folder for TinyCamPublish into "add file" but it is not letting me. I think I am struggling with pushing the entire folder into Github.

SUPScientist commented 5 months ago

I use the Terminal (command line interface or CLI) not GitHub desktop which is what I believe you use, so my workflow is different. Does this help: https://docs.github.com/en/desktop/adding-and-cloning-repositories/adding-a-repository-from-your-local-computer-to-github-desktop?

This looks like a very relevant thread as well: https://github.com/orgs/community/discussions/21962

BentleySettin commented 5 months ago

Okay I will look into these. I need to just commit set apart time from the lab to edit this all.

I ran an updated Publish code with publishing = 0 (OFF) and the boron is trying to connect to wifi still, flashing green. Based on the code it should result on cellular off and begin the switch states. It started flashing light blue which means it is trying to connect to internet which is when I terminated it immediatley.

BentleySettin commented 5 months ago

@SUPScientist I may not be understanding this correctly. I have publishing to 0 and still the Boron tries to connect to internet and then even tries to connect to the cloud (cyan blinking). I have the if else statement purposely set turn cellular off just to test the rest of the code from the open-water-level sensor code.

Thank you!

SUPScientist commented 5 months ago

Two thoughts:

  1. Did you make sure to flash application and DeviceOS (local)? Maybe if the Boron you're using has a newer version of DeviceOS than the one that you're compiling/flashing for, there could be an internal conflict leading it to think it's supposed to try to connect automatically even if your firmware tells it not to.
  2. I can review your script better once the whole project folder is committed to github.
BentleySettin commented 5 months ago

Yes I did and it is committed here.

SUPScientist commented 5 months ago

What is the response to particle serial identify executed in the Particle CLI when the Boron is in listening mode? You may have to run it a few times to get a full response. Paste here only the DeviceOS version #, please (i.e., don't paste device ID).

BentleySettin commented 5 months ago

system firmware version is 4.0.2

SUPScientist commented 5 months ago

OK, doesn't seem to be a system firmware issue, then, so seems that it must be a user firmware (i.e., the .ino file) issue. Please keep committing changes to your .ino file as you work to troubleshoot this and I will continue to review to see if anything catches my eye. It'd also help to see better formatted code, such as what you get when you copy your script into https://codebeautify.org/cpp-formatter-beautifier and paste the results back into the .ino file. It shouldn't change anything other than aesthetics but it'll help follow the script more easily.

BentleySettin commented 5 months ago

Will do. Does it take some time for a commit off github desktop to show in the repository? I committed updated code a few minutes ago and it is still not showing.

image

This is what I am looking at. It shows I commited the new code but do not see it yet.

SUPScientist commented 5 months ago

I use the command line interface (CLI) not GH Desktop, but I imagine the steps are the same:

My guess is that you haven't done step 3, maybe? https://docs.github.com/en/desktop/making-changes-in-a-branch/pushing-changes-to-github-from-github-desktop

BentleySettin commented 5 months ago

Wonderful got it! You should be able to see the beuatified code here

BentleySettin commented 5 months ago

So I took out even the possibility for the Boron to connect to internet and publish to see if it would run through the switch states. It is continuing to flash green to connect to internet. Looking around in the code to make sure there is nothing there causing it to try to connect.

BentleySettin commented 5 months ago

@SUPScientist Do you think this has to do with the addition of the antenna?

The second I plug in the Boron to USB it goes straight to trying to connect to internet.

SUPScientist commented 5 months ago

No, it's not the antenna. It has to be a firmware issue. You can run your own tests, such as using an old script that didn't have cell but that you know compiled and flashed. Keep the antenna on during the test to prove this to yourself. This is part of the rationale for creating new repos as "mile markers" when you cross a specific threshold, so that you can lock functional code in place and always be able to return to it when things go haywire.

BentleySettin commented 5 months ago

Yes, I tried the updatedBoron code that has proven to work in the past but when I try to flash it now it is not working. The boron just tries to connect to internet.

In the code I am currently working on now, I put a serial print "hello world" after the if-else statement to either publish or turn cell off and it does not print.

BentleySettin commented 4 months ago

I am currently at the point where the OpenMV and Boron are able to turn on and off periodically and Boron is printing to the serial monitor data with all its variables. I found the correct format for the string in data. Currently in the serial monitor i am recieving the off images (�2☻) again in place of flood or No flood.

I am trying to determine if its a timing error which seems unlikely to me because the openMV is on the Boron's external interrupt.

SUPScientist commented 4 months ago

Sounds like progress! Your last commit in this repo was last week, so I'm guessing you have newer code? Remember to please ALWAYS ALWAYS commit and push code after making changes and consider linking to specific files in your commit messages when relevant so that we can look closer.

BentleySettin commented 4 months ago

https://github.com/TinyCamML/Boron-and-OpenMV/commit/a4b86a206f32f215cfd6dce1fff2837146b9b44e

Here is the newer code! committed and pushed !

BentleySettin commented 4 months ago

updated code here

I am recieving the same issue with weird variable responses for the flood or no flood.

BentleySettin commented 4 months ago

I reverted back to the code used UART communications between Boron and OpenMV which has worked in the past. This is not working now and the openMV is just flashing blue which I am looking into now.

SUPScientist commented 4 months ago

Recommend verifying OpenMV operations independently. Have you seen OpenMV print flood/no flood to its IDE's serial monitor when hooked up to its own USB cable (i.e., removing the Boron from the loop)? I recommend stripping back complexity until you get to something that verifies functionality, then building complexity back in one step at a time and verifying functionality at each step that you add.

BentleySettin commented 4 months ago

Yes it works on the IDE serial monitor. I edited part of Evan's code which I will recommit if it works. Looks like the code from Evan kept the openmv on without actually falling asleep which is why i was previously using machine.sleep. Therefore this had the openmv flashing blue telling me it was reading and printing flood/no flood without any breaks. This may have been (1) causing the openmv to apear to be flashing blue which I was interpretting as a hardware error (2) why the VS serial monitor keeps printing weird numbers because the timing is off.

Testing all this now.

BentleySettin commented 4 months ago

@SUPScientist It works! Had to change a bit of both codes and recommitting now!

currently what i am looking at on VS serial monitor:

946684803,Flood,1.25,47.71 going to sleep Sleeping for 56

ebgoldstein commented 4 months ago

@BentleySettin - is this the commit? https://github.com/TinyCamML/Boron-and-OpenMV/commit/8916227a3f2c438f0915c54614141719e03c15b2.

if so, does it solve this issue? I ask because I'm wondering if you can now close this issue?

If this issue still needs to be open, can you explain what the next steps are to be able to close the issue? I just want to make sure that all the comments/discussion in the issue is concretely connected to closing the issue at hand, and there is a clear roadmap to do it.

(i say this also because this issue has a title, but no real description/action items.. like 'step 1: do this, step 2, do that'... etc.)

BentleySettin commented 4 months ago

Yes! Just reupdated it. https://github.com/TinyCamML/Boron-and-OpenMV/commit/a73a2d89ecc041749dbf780870dfa5da932aa2f8

I had to remove a hello statement but yes this issue is now solved