| | 1 | #include "config.h" |
| | 2 | |
| | 3 | /* Wi-Fi credentials */ |
| | 4 | const char config_wifi_ssid[] = "THEWIFISSID"; |
| | 5 | const char config_wifi_pass[] = "THEWIFIPASSWORD"; |
| | 6 | |
| | 7 | /* Network address of the server to contact */ |
| | 8 | const char config_tattle_server_ip_address[] = "192.168.10.10"; |
| | 9 | const u16_t config_tattle_port = 29803; // 'tk' |
| | 10 | |
| | 11 | /* For distinguishing reports from multiple tattlekey devices. */ |
| | 12 | const u16_t config_this_tattler_identity = 1; |
| | 13 | |
| | 14 | /* Which GPIO pin is the button connected to? |
| | 15 | * The button should span this pin and ground, connecting this pin to ground |
| | 16 | * when pressed. |
| | 17 | * https://projects.raspberrypi.org/en/projects/introduction-to-the-pico/10 |
| | 18 | * recommends pins 18, 22, or 28. */ |
| | 19 | const uint config_button_pin = 18; |
| | 20 | |
| | 21 | /* Don't bother reporting each separate button press when it is pressed many |
| | 22 | * times in short succession. (We also use this to de-bounce. :) */ |
| | 23 | const u32_t config_minimum_seconds_between_button_presses = 1; |
| | 24 | |
| | 25 | /* Send each report multiple times. Re-sends are sent with exponential delay: |
| | 26 | * #1 sent immediately |
| | 27 | * #2 after 1 seconds |
| | 28 | * #3 after 2 seconds |
| | 29 | * #4 after 4 seconds |
| | 30 | * #5 after 8 seconds |
| | 31 | * ... |
| | 32 | * #11 after 8 minutes |
| | 33 | * #12 after 17 minutes |
| | 34 | * #13 after 34 minutes |
| | 35 | * #14 after 68 minutes |
| | 36 | * #15 after 2 hours |
| | 37 | * #16 after 4 hours |
| | 38 | * #17 after 9 hours |
| | 39 | * etc. |
| | 40 | * This provides some robustness against network outages, automatically |
| | 41 | * replaying the log periodically to be collected after connectivity |
| | 42 | * is restored. */ |
| | 43 | const uint config_resend_count = 16; |
| | 44 | |
| | 45 | /* These control the size of the per-send-count press queues. |
| | 46 | When the button is pressed more than config_maximum_queue_size times |
| | 47 | within the resend interval, some presses will be reported fewer |
| | 48 | than config_resend_count times. This is usually fine because it's |
| | 49 | the old, longest-delayed, most-redundant reports that get dropped; |
| | 50 | fresh, timely reports of new button presses will not get anywhere near |
| | 51 | config_resend_count in a resend interval because the early resend internals |
| | 52 | are so short. */ |
| | 53 | const uint config_maximum_queue_size = 512; |
| | 54 | |
| | 55 | /* This is paranoia about unanticipated delays. Setting this to zero |
| | 56 | would probably be fine, but imposing a minimum queue size is an easy |
| | 57 | safety measure. */ |
| | 58 | const uint config_minimum_queue_size = 32; |
projects / tattlekey / blame_incremental