 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite V6.00.00 release candidates - all versions
  Page 21 of 22   |
|||||
| Author | Message | ||||
stanleyella Guru  Joined: 25/06/2022 Location: United KingdomPosts: 2108 |
I use option list PicoMiteHDMI MMBasic USB Version 6.00.00RC15 OPTION SERIAL CONSOLE COM2,GP8,GP9 OPTION AUTORUN ON OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION KEYBOARD UK, 0, 0, 600, 150 OPTION CPUSPEED (KHz) 315000 OPTION HDMI PINS 1, 3, 7, 5 OPTION SDCARD GP22, GP6, GP7, GP4 OPTION AUDIO GP26,GP27', ON PWM CHANNEL 5 OPTION MODBUFF ENABLE 192 |
||||
karlelch Senior Member  Joined: 30/10/2014 Location: GermanyPosts: 170 |
Thanks but the pins for the SD card are defined by the carrier board; I cannot change them on the hardware side. Best Thomas |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6757 |
On the USB keyboard system you still need a console connection as the USB port is now in Host mode. The default is to re-use GP8 and GP9, which are COM2, for this. You can use OPTION SERIAL CONSOLE to use any valid pair of COM port pins instead of GP8 and GP9. Note that they have to be on the same hardware UART port and it can't be shared with anything else. The default baud rate is 115200 but you can change it using OPTION BAUDRATE. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| karlelch Senior Member Joined: 30/10/2014 Location: GermanyPosts: 170 |
Hi Mick Many thanks! This worked! Now I can also run the file manager  .I'll post the complete options in the thread about that board. Best Thomas |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6089 |
More on the DHT22 saga. I have tested on 2 different RP2040s (picomite and WEBmite) and 4 different DHT22s V6RC10 works as expected.V6RC11 and later are unreliable at best. The 'best' DHT22 can give valid results for a few minutes but then back to 1000 The start pulse appears correct and the DHT22 always responds with a valid looking data-stream. The trace is nice and square so pullup of 4.7k is correct. The timing for the zero and one are 26uS and 75uS so all within specs. Visually checking on the CRO gives a correct checksum. My best guess is the timing is having frequent hickups. The only problem with that is, Phil appear to have no issues with his DHT11. The timing code for both units is the same. Jim VK7JH MMedit MMBasic Help |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2129 |
It's a puzzle alright. Have run it for many hours on both Pico1 & 2 and just get an occasional "1000 1000", as has always been the case. Once or twice per hour perhaps. I use a 30S update interval instead of the 2S minimum to improve the accuracy of the humidity, but that should make no difference to to the functioning. As the issue is common to all that you have tested could it be related to power supply? More filtering perhaps? Mine are run from the USB lead. The 2040 had an extra 10µF on 3.3V, however removing it made no difference. Does anyone else have a DHT22 or 11 they could test on RC15? It would help to determine if Jim has just been unlucky or if mine is abnormal. Edited 2024-11-17 17:33 by phil99 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9080 |
DHT11 definitely works when tested on RC15. Haven't got a DHT22. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6089 |
I can't leave it alone... The test program: ' ' n = number of bad readings in a row ' k = number of good readings in a row DO DEVICE HUMID GP17, tmpr,hmid,0 IF tmpr = 1000 THEN INC n k = 0 ELSE INC k PRINT tmpr,hmid, n,k n = 0 ENDIF PAUSE 5000 LOOP PicoMite RP2350A Standard Pico2 board PicoMite MMBasic Version 6.00.00RC15 Heavy breathing causes readings to fail and start giving true readings after the humidity drops below ~60% Readings are Humidity, Temperature, Num bad readings, Num of good readings 17.9 55 0 1700 18 55 0 1701 17.9 55 0 1702 18 54.9 0 1703 17.9 82.5 0 1704 18 58.4 8 1 18 57.8 0 2 18 57.6 0 3 18 57 0 4 18 56.9 0 5 18 56.8 0 6 PicoMite MMBasic Version 6.00.00RC9 Heavy breathing is detected OK without any problems. 18.2 55.7 0 56 18.2 55.4 0 57 18.2 55.4 0 58 18.2 55.1 0 59 18.3 99.9 0 60 18.3 94 0 61 18.3 78.4 0 62 18.2 69.9 0 63 18.3 67.1 0 64 18.3 65.3 0 65 18.2 62.1 0 66 18.3 61.2 0 67 18.2 60.7 0 68 If I had a small change to the DHT22 error_exit code in 'PicoMite RP2350' it might give further insight. A humidity of -1 means timeout while any other value can be used to estimate where the misread occured. The DHT11 has different raw values for humidity so it is unlikely that the same issue occurs with that module. error_exit: *temp = 1000.0; // an obviously incorrect reading *humid = (MMFLOAT)r ; VK7JH MMedit MMBasic Help |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 896 |
I compared the source for RC9 and RC15. There is this extra validation in RC15 which will reject the reading. Based on Jim's finding that the actual humidity reading can affect the results, maybe this validation is not doing as expected. if((uint8_t)((r>>32) & 0xFF) + (uint8_t)((r>>24) & 0xFF) + (uint8_t)((r>>16) & 0xFF) + (uint8_t)((r>>8) & 0xFF) != (uint8_t)(r & 0xFF))goto error_exit; Is this allowed? if((unit8_t)(uint8_t)((r>>32) & 0xFF) + (uint8_t)((r>>24) & 0xFF) + (uint8_t)((r>>16) & 0xFF) + (uint8_t)((r>>8) & 0xFF) != (uint8_t)(r & 0xFF))goto error_exit; Edited 2024-11-18 15:12 by disco4now Latest F4 Latest H7 |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2129 |
Great detective work! If Humid is going to be edited may I make a request? Could the DHT11 tenths of degrees (byte 4 in the 40 bit stream) be added? The temperature accuracy of the DHT11 isn't too bad if the sample interval is greater than 5S. This is how I currently do it. Edited 2024-11-18 17:08 by phil99 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9080 |
I suppose DHT11 may vary but my versions NEVER put anything in byte 2 or byte 4. I'll have a look again at the validation. I changed it because the original was definitely wrong but suspect it should be if( ( (uint8_t)( ((r >> 8) & 0xff) + ((r >> 16) & 0xff) + ((r >> 24) & 0xff) + ((r >> 32) & 0xff) ) ) != (uint8_t)(r & 0xff)) goto error_exit; // returning temperature Edited 2024-11-18 17:58 by matherp |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2129 |
In my DHT11 byte 2 is always 0 (probably reserved for tenths of % H) but byte 4 varies from 0 to 9 as the temperature changes. When the temp. goes up 1° byte 3 jumps from 9 to 0. Always within 0.5°C of the AHT10. DS18B20 DS18B20 DS3231 AHT10 DHT11 DHT11 reading method 18.3 17.1 16.25 16.5C 37.5% 16.8C 44% Device HUMID,0 + extra 20mS wake pulse |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9080 |
Phil and Jim Please try this RP2040 VGA version (don't need VGA H/W to run it). In theory the xsum check is now correct and it should do tenths on the DHT11 temperature (but who knows) PicoMite.zip I don't have anything to test with for the next few days so this is completely untested Edited 2024-11-19 00:38 by matherp |
||||
| Michal Senior Member Joined: 02/02/2022 Location: PolandPosts: 123 |
I'm a little confused, what's the difference between the USB and non-USB versions? Michal |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6089 |
Sorry Peter, no change with the DHT22 Jim VK7JH MMedit MMBasic Help |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2129 |
Thank you Peter, the DHT11 change was a success. > do :humid gp0,t,h,1 :? t,h :pause 30000 :loop 12.9 45 13 46 13.1 46 13.1 46 13.4 46 14.2 45 15.4 44 16.8 44 18.1 43 19 42 19.5 41 20.1 40 20.5 40 |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6089 |
I have dug a bit deeper. Using the ADC to decode the data stream, I discovered that the 'bad' readings occur when bit 9 of the stream is a 1. bit 9 of the stream is the high bit of the second byte. Sign bit? I expect that any byte would do the same. Line 1 is the decoded data which should be the same as 'r' in the code line 2 is my calculated values line 3 is the MMBasic results. 0000001000000011000000001011010110111010 1 18.1 51.5 18.1 51.5 0000000111111001000000001011010110101111 1 18.1 50.5 1000 1000 0000000111111111000000001011010110110101 1 18.1 51.1 1000 1000 0000001010001001000000001011011001000001 1 18.2 64.9 1000 1000 0000001001001100000000001011011000000100 1 18.2 58.8 1000 1000 0000001001000011000000001011011011111011 1 18.2 57.9 18.2 57.9 0000001000111000000000001011010111101111 1 18.1 56.8 18.1 56.8 0000001000100100000000001011011011011100 1 18.2 54.8 18.2 54.8 Jim VK7JH MMedit MMBasic Help |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2129 |
So I guess this could also affect the DHT11. None of it's 4 data bytes can have 1 in the top bit but the checksum byte can. Eg, in Darwin a humidity of 90% and temp. of 30.8°C would give a checksum of 128. Edited 2024-11-19 08:30 by phil99 |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6089 |
I don't think the checksum matters. That's based on my interpretation of my obs. I claim no knowledge of c types and casting and all that black magic. VK7JH MMedit MMBasic Help |
||||
| disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 896 |
We were here for the DHT22 in 2015 on the micromite.I think its a combination of Temp and Humid that causes an overflow when the adding the 4 bytes of data to calculate the checksum. MM2: DHT22 Is there an issue? Latest F4 Latest H7 |
||||
| Page 21 of 22 |
|||||
 Print this page |
