mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2024-11-10 07:34:11 -08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Update FAQ, Driver information and S&F

Browse source
This commit is contained in:
Jm Casler 2021-11-21 09:31:51 -08:00
parent 57512460a9
commit a97581876e
3 changed files with 24 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
website/docs/getting-started/faq.md
View file

@ -36,8 +36,8 @@ Q: How can I contribute to Meshtastic?
Q: Where do I purchase the device hardware? Q: Where do I purchase the device hardware?
* Answer TBD * Answer TBD
Q: I have my hardware. How do I install the firmware? Q: I have my hardware. How do I install the firmware and any required drivers?
* Answer TBD * See: https://meshtastic.org/docs/getting-started/flashing-esp32
Q: How do I update the firmware to the latest version? Q: How do I update the firmware to the latest version?
* Answer TBD * Answer TBD
@ -48,8 +48,11 @@ Q: My device has gone to sleep. Are received messages lost?
Q: My device has gone to sleep and I can't send any messages. Q: My device has gone to sleep and I can't send any messages.
* Once the node wakes up from sleep, your phone will relay any delayed messages through your node and to the mesh network. Give it a few minutes and it'll do the right thing. * Once the node wakes up from sleep, your phone will relay any delayed messages through your node and to the mesh network. Give it a few minutes and it'll do the right thing.
Q: How do I turn on / off an esp32 tbeam based device? Q: How do I turn off an esp32 tbeam based device?
* Answer TBD * Hold down the middle button for about 10 seconds.
Q: How do I turn on an esp32 tbeam based device?
* Push the power button for about 1 second.
Q: How can I tell the device not to sleep? Q: How can I tell the device not to sleep?
* Android instructions see: [Android Usage](https://meshtastic.org/docs/software/android/android-usage#configuration-options) * Android instructions see: [Android Usage](https://meshtastic.org/docs/software/android/android-usage#configuration-options)

2
website/docs/getting-started/flashing-esp32.md
View file

@ -13,6 +13,8 @@ import TabItem from '@theme/TabItem';
Plug your device into your computer using a USB cable and then do the following: Plug your device into your computer using a USB cable and then do the following:
:::important :::important
You may need to install a driver from Silicon Labs for the [CP210X USB to UART bridge](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers) You may need to install a driver from Silicon Labs for the [CP210X USB to UART bridge](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers)
Some newer boards may require the drivers for the [CH9102 USB to UART bridge](https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/drivers/CH9102_VCP_SER_Windows.exe) on Windows 7.
::: :::
<Tabs <Tabs

15
website/docs/software/plugins/store-forward.md
View file

@ -79,14 +79,25 @@ Not necessarily in this order:
* Be able to identify if you're within range of a router. * Be able to identify if you're within range of a router.
* Be able to specify the HOP MAX to reduce airtime. * Be able to specify the HOP MAX to reduce airtime. Is this necessary?
* Restrict operation of S&F on the slow channel configurations. * Restrict operation of S&F on the slow channel configurations.
*/ * Create a tx queue to prevent the history from being modified in flight.
* Only allow n-number of requests to the router at any one time.
* Set number of max messages from the history.
* Calculate a new channel with 250mhz bandwidth and ~1.5kbit.
*** Done *** Done
* Disable ACK. If the router is within range, so is the requester.
* Currently the way we allocate messages in the device code is super inefficient. It always allocates the worst case message size. Really we should dynamically allocate just the # of bytes we need. This would allow many more MeshPackets to be kept in RAM. * Currently the way we allocate messages in the device code is super inefficient. It always allocates the worst case message size. Really we should dynamically allocate just the # of bytes we need. This would allow many more MeshPackets to be kept in RAM.
* Allow max history to be defined by radioConfig.preferences.store_forward_plugin_records * Allow max history to be defined by radioConfig.preferences.store_forward_plugin_records
* Add a starting to send / finished sending message