!arduino_projects_etc@lemmy.staphup.nl
!arduino_projects_etc
@lemmy.staphup.nlhttps://www.youtube.com/watch?v=eIdHBDSQHyw
Code/Writeup/Resources: https://github.com/cnlohr/lolraPatreon: https://patreon.com/cnlohrMemes, in order of appearance: Tiny Paper Senior Chang, Trollface R...
https://lemmy.ml/post/3577768
(me again) i’m trying to use both WIFI-AP, DO and SPI. But my wifi is not properly working when i let everything run at maximum (required) speed. TLDR; Seems that pins D1 and D2 interfere with WIFI, but why? i have a NodeMCU ESP8266 V3 ‘wemos’ variant. (it doesn’t have the ESP-12E board integrated) https://makerselectronics.com/product/wemos-nodemcu-v3-esp8266-340g-wifi-module-with-extra-memory-32m-flash [https://makerselectronics.com/product/wemos-nodemcu-v3-esp8266-340g-wifi-module-with-extra-memory-32m-flash] in setup() i have WiFi.softAP(ssid, password); IPAddress myIP = WiFi.softAPIP(); Serial.print("AP IP address: "); Serial.println(myIP); server.on("/", handleRoot); server.on("/set_config", handleForm); server.onNotFound(handleNotFound); server.begin(); .. t=D1;pinMode(t, OUTPUT); digitalWrite(t, LOW); t=D2;pinMode(t, OUTPUT); digitalWrite(t, LOW); t=D3;pinMode(t, OUTPUT); digitalWrite(t, LOW); What i’m seeing; if i have a main loop() with only - while (Serial.available()){ … } - server.handleClient(); Then i can see the AccessPoint and i can connect to it with my Android phone. When i add code running once every 100 msec - Debug setting set to MAX debug info to Serial - using pins D1,D2,D3 for output (to LED screen) - using D5,D7 for SPI, (to LED screen) - having SPISettings(15000000, MSBFIRST, SPI_MODE0) - taking total 60 up to 74 microseconds Then i do see the WIFI AP, and i CAN connect with the WIFI AccessPoint. (But my LED display is flickering) When i change the code to running once every 10 msec - // same as before Then i CAN connect with the WIFI AccessPoint (But my LED display is flickering) When i change the code to running once every 10 msec - Debug setting off - using pins D1,D2,D3 for output - using D5,D7 for SPI - taking total 60 up to 74 microseconds Then i CAN connect with the WIFI AccessPoint (But my LED display is flickering) When i change the code to running once every 1 msec - Debug setting None + Debug to serial - using pins D1,D2,D3 for output - using D5,D7 for SPI - taking total 60 up to 74 microseconds Then i do see the WIFI AP, but i CAN’T connect with the WIFI AccessPoint (But my LED display is showing a steady picture) When i change the code to running once every 1 msec - Debug setting None + Debug disabled - using pins D1,D2,D3 for output - NOT using D5,D7 for SPI - taking total 30 up to 40 microseconds Then i do NOT see the WIFI AP?! When i change the code to running once every 1 msec - Debug setting None + Debug disabled - NOT using pins D1,D2,D3 for output - using D5,D7 for SPI - taking total 50 up to 70 microseconds Then i CAN connect with the WIFI AccessPoint?! Seems one of the pins D1,D2,D3 is interfering with WIFI… instead of using D1,D2,D3, i changed all I/O to only use D1. Then the WIFI AP does not show up in the WIFI networks. instead of using D1,D2,D3, i changed all I/O to only use D2. Then the WIFI AP does not show up in the WIFI networks. instead of using D1,D2,D3, i changed all I/O to only use D3. Then the WIFI AP does show up in the WIFI networks. And i can connect to it. So my question is; Seems that pins D1 and D2 interfere with WIFI, but why?
https://youtu.be/26KyoSo_Hvs?t=30
Jonathan Bennett and Doc Searls speak with lead developers of Meshtastic Ben Meadors and Garth Vander Houwen about Meshtastic on FLOSS Weekly. What is Meshta...
I've got a few damaged hoverboards. They're not very good quality. Some work others go into error-state after a while.
To be able to do some fault finding i thought to try to readout what these sensorboards provide.
This is the exact model i have
Sensorboard gyroscope taotao 684270 2016-04-20 (where i found the pics: https://www.voltes.eu/products/hoverboard-sensorboard-gyroscope-taotao)
i use the Arduino mega 2560, because it has multiple UART pins.
I first needed to know the baud rate. For that i found some online arduino code measuring the shorted pulse duration, and based on that determine the baud rate. Seems the board is communicating at 57600 baud.
To try to find out what UART mode is used, i created a program which determines the high/low durations of the data pin, and print it as a bitstream, hoping to be able to determine the mode. But i couldn't make sense of it(in hindsight, i can understand it, but i'm too much of a rookie). So i just tried the few available modes. None of the 5 to 8 databits modes produced anything useful.
Turns out the standard Arduino 8 bit UART modes don't work. i needed to try the 9 bit UART mode. For that i used an external library mentioned on this site: https://forum.arduino.cc/t/9-bit-software-hardware-serial/590266/8 Because this library sets an interrupt routine, i renamed the HardwareSerial9bit0.cpp file to HardwareSerial9bit0.cpp.txt so that in my sketch it didn't collide with the Arduino IDE's Serial which i used for debug printing to the Arduino console. The mode which worked for Serial91 is SERIAL_9O2 (9 databits, Odd parity, 2 stopbits )
To find the start of a frame, i decided to look for a 0, then 2 times a non-0, and a 0 after the frame. For storing the UART data in a buffer, i used the CircularBuffer library by AgileWare v1.3.3 https://github.com/rlogiacco/CircularBuffer . I set it to store 512 integers. When Arduino finished 1 cycle, there are between 10 and 60 integers read into the buffer. But when i enable printing of packets to Serial, then it increases to about 70 - 80 per cycle which are available. When the cyclical buffer contains more then 10 integers, i test if it contains a valid frame, if not, i remove the head, and test again. Update: I changed the frame detection because an actual 0 angle would not be possible. So now it tests for #0 to be 0, #5 to be 0x5 or 0xA, #10 to be 0. Also, i now realize that UART overflows at 64 characters.. i.e. the code must be improved to be faster. /update
The data packets are formatted as
* 000,102,002,102,002,01A,0B8,0B8,000,000,000,
* AA BB AA BB CC DD DD EE EE FF
* 000 = Start of frame
* AA BB = LSB,MSB forward backward angle
* CC = Status bits ( 0xA unpressed, 0x5 pressed, 0x20 Error/was upside down )
* DD = 9 bit unsigned 0..185..368 intertia left/right rotation
* EE = 9 bit signed -255.. +255 intertia forward/backward rotation
* FF = Start of next frame
The doubling of the data in a single frame enables some error checking. I observed the next issue
AA BB AA BB CC DD DD EE EE | 'AABB as dec nr' || Bad
Angle reading is dodgy.. Bits are flipping on.offf
V V V V
63 | 1E1 | 63 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15773 ||
63 | 1F1 | 63 | 1F1 | 5 | B8 | B8 | 0 | 0 | -7581 || BAD
73 | 1E1 | 73 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15757 || BAD
63 | 1E1 | 63 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15773 ||
63 | 1E1 | 63 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15773 ||
73 | 1F1 | 73 | 1F1 | 5 | B7 | B7 | 0 | 0 | -7565 || BAD
63 | 1E1 | 63 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15773 || BAD
73 | 1F1 | 73 | 1F1 | 5 | B8 | B8 | 0 | 0 | -7565 || BAD
63 | 1E1 | 63 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15773 || BAD
72 | 1E1 | 72 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15758 ||
62 | 1E1 | 62 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15774 ||
62 | 1F1 | 62 | 1F1 | 5 | B8 | B8 | 0 | 0 | -7582 || BAD
62 | 1E1 | 62 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15774 || BAD
62 | 1F1 | 62 | 1F1 | 5 | B8 | B8 | 0 | 0 | -7582 || BAD
72 | 1E1 | 72 | 1E1 | 5 | B8 | B8 | 0 | 0 | -15758 || BAD
But i actually can't figure out which of the reading is 'BAD' i just picked the one which changed much in angle from the previous frame, while accelerometer(EE) says 0. i figured that if the angle changes much, then the accelerometer should also indicate movement.
After logging the packages and trying to find a way to read only valid frames, i used an LCD 20x4 I2C screen to show some statistics. For that i used LCD Library by Frank de Brabander v 1.1.2 https://github.com/johnrickman/LiquidCrystal_I2C
I show a databar for the
and the following info
My total setup looks like this
For the presentation not to take too much CPU time, the top 3 bars refresh every 100 msec, the bottom numbers refresh every 500 msec. i Also changed LiquidCrystal_I2C\LiquidCrystal_I2C.cpp to set the I2C speed to 400Khz by calling setClock()
void LiquidCrystal_I2C::init_priv()
{
Wire.begin();
Wire.setClock(400000); // Set I2C to 400Khz
_displayfunction = LCD_4BITMODE | LCD_1LINE | LCD_5x8DOTS;
begin(_cols, _rows);
}
Next up.. Trying to figure out what sensor-data is acceptable by the main board and which data makes the main-board go into error state.
https://www.analog.com/en/technical-articles/protecting-adc-inputs.html
https://www.youtube.com/watch?v=mdqRTOAQLNE
Arduino na Shopeehttps://shope.ee/7UlXL85Unthttps://shope.ee/5V0SxYJHN2Caro inscrito,A comunicação serial está implementada via software devido às limitações...
https://media.ccc.de/v/gpn18-95-howto-moving-objects#t=1259
Reverse engineering Hoverbard hardware for fun. In this talk you will learn how to flash your Hoverboard hardware with custom firmware t...