Skip to content
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

Update my fork from head with 1.1 changes #13

Merged
merged 26 commits into from
Oct 7, 2020

Conversation

mc-hamster
Copy link
Owner

Thank you for sending in a pull request, here's some tips to get started!

(Please delete all these tips and replace with your text)

  • Before starting on some new big chunk of code, it it is optional but highly recommended to open an issue first
    to say "hey, I think this idea X should be implemented and I'm starting work on it. My general plan is Y, any feedback
    is appreciated." This will allow other devs to potentially save you time by not accidentially duplicating work etc...
  • Please do not check in files that don't have real changes
  • Please do not reformat lines that you didn't have to change the code on
  • We recommend using the Visual Studio Code editor,
    because automatically follows our indentation rules and it's auto reformatting will not cause spurious changes to lines.
  • If your PR fixes a bug, mention "fixes #bugnum" somewhere in your pull request description.
  • If your other co-developers have comments on your PR please tweak as needed.

geeksville and others added 26 commits September 26, 2020 06:50
Update readme to link to the US aliexpress listing
Signed-off-by: Kevin Hester <kevinh@geeksville.com>
bogus wakes on TBEAMS because the USB->SERIAL chip pulls the RX input
to ground.  This feature is no longer needed because in !isRouter
nodes we force the node to never sleep anyways when on USB power.

    // this doesn't work on TBEAMs when the USB is depowered (causes bogus interrupts)
    // So we disable this "wake on serial" feature - because now when a TBEAM (only) has power connected it
    // never tries to go to sleep if the user is using the API
    // gpio_wakeup_enable((gpio_num_t)SERIAL0_RX_GPIO, GPIO_INTR_LOW_LEVEL);
…ress

Could cause hangs on the way into sleep (and enormous power consumption).
Instead of checking for rx packet length (which only changes at completion)
check if we've received preamble bits but haven't yet received a completed
packet interrupt.

notes:


wait to sleep loop problem
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
Can not send yet, busyRx
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0

vs normal run
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
Starting low level send (id=0x53fe1dd0 Fr0xe5 To0xff, WantAck0, HopLim3 encrypted)
Completed sending (id=0x53fe1dd0 Fr0xe5 To0xff, WantAck0, HopLim3 encrypted)
major cleanup of GPS code and changes to keep GPS asleep
@mc-hamster mc-hamster merged commit dffcea1 into mc-hamster:master Oct 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants