Jump to content

darethehair

Members
  • Posts

    20
  • Joined

  • Last visited

  1. Update: Success! Some articles that I read, including the one here, suggest using PA19/PA18 instead of PA12/PA11, so I swapped my wires around. I also followed the suggestion to wire SDO to GND as that article mentions. After doing this, and rebooting, the code I was trying started to work. Why? I have no idea, but I am happy. Next (small) hurdle -- deal with the expected distorted values being encountered while the BME280 sensor is in the same coffee can as the Orange Pi Thanks Martinayotte!
  2. Hello! Thanks for your suggestions. Changing the 'bus_number' had no effect. I implemented the python library you suggested, but I have not found app code specifically to test the BME280. All of the code I have tested so far results in some sort of failure. The latest one (from blackmagicboxes) results in the following: darren@frodo10:~/Downloads/bmp280_p$ ./bme280_p Failed to open the bus. With successful 'i2cdetect', can I be confident my device is working and wired correctly i.e. that my problems are just a 'software' issue?
  3. Hello Folks! Already successfully running an RTL-SDR device (for Flight Tracking) and U-Blox NEO-6M GPS (for GPS/NTP) on my Orange Pi PC Plus, and now wanted to try a BME280 weather chip, but ran into problems talking to it. The 'i2cdetect' seems to be working fine: darren@frodo10:~$ sudo i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- 76 -- However, after many Googles with both C and Python code, I can't seem to successfully talk to this device In my last attempt (using bme280_sample.py and modifying the reference to 0x76, installing 'smbus2', etc.): darren@frodo10:~/Downloads$ sudo python bme280_sample.py Traceback (most recent call last): File "bme280_sample.py", line 138, in <module> setup() File "bme280_sample.py", line 133, in setup writeReg(0xF2,ctrl_hum_reg) File "bme280_sample.py", line 19, in writeReg bus.write_byte_data(i2c_address,reg_address,data) File "/usr/local/lib/python2.7/dist-packages/smbus2/smbus2.py", line 391, in write_byte_data ioctl(self.fd, I2C_SMBUS, msg) IOError: [Errno 6] No such device or address Does the 'ic2detect' output mean that I have everything wired up properly? Am I close to success?
  4. Made a video. Gave some appropriate credit to Armbian https://www.youtube.com/watch?v=hfUwu250czk&amp;feature=youtu.be
  5. Out of curiosity, I installed the 'WiringOP' app so that I could view the 'gpio readall' output. Here is what happens when I do so: darren@frodo10:~$ gpio readall +-----+-----+----------+------+---+-Orange Pi+---+---+------+---------+-----+--+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 12 | 8 | SDA.0 | ALT3 | 0 | 3 || 4 | | | 5V | | | | 11 | 9 | SCL.0 | ALT3 | 0 | 5 || 6 | | | 0v | | | | 6 | 7 | GPIO.7 | ALT2digitalRead(): Failed to open /sys/class/gpio/gpio6/value, pin not exported? | 0 | 7 || 8 | 0 | ALT4 | TxD3 | 15 | 13 | | | | 0v | | | 9 || 10 | 0 | ALT4 | RxD3 | 16 | 14 | | 1 | 0 | RxD2 | ALT3 | 0 | 11 || 12 | 0 | ALT3 | GPIO.1 | 1 | 110 | | 0 | 2 | TxD2 | ALT3 | 0 | 13 || 14 | | | 0v | | | | 3 | 3 | CTS2 | ALT3 | 0 | 15 || 16 | 0 | ALT3 | GPIO.4 | 4 | 68 | | | | 3.3v | | | 17 || 18 | 0 | ALT3 | GPIO.5 | 5 | 71 | | 64 | 12 | MOSI | ALT3 | 0 | 19 || 20 | | | 0v | | | | 65 | 13 | MISO | ALT3 | 0 | 21 || 22 | 0 | ALT3 | RTS2 | 6 | 2 | | 66 | 14 | SCLK | ALT3 | 0 | 23 || 24 | 0 | ALT3 | CE0 | 10 | 67 | | | | 0v | | | 25 || 26 | 0 | ALT3 | GPIO.11 | 11 | 21 | | 19 | 30 | SDA.1 | ALT3 | 0 | 27 || 28 | 0 | ALT3 | SCL.1 | 31 | 18 | | 7 | 21 | GPIO.21 | ALT3 | 0 | 29 || 30 | | | 0v | | | | 8 | 22 | GPIO.22 | ALT3 | 0 | 31 || 32 | 0 | ALT3 | RTS1 | 26 | 200 | | 9 | 23 | GPIO.23 | ALT3 | 0 | 33 || 34 | | | 0v | | | | 10 | 24 | GPIO.24 | ALT3 | 0 | 35 || 36 | 0 | ALT3 | CTS1 | 27 | 201 | | 20 | 25 | GPIO.25 | ALT3 | 0 | 37 || 38 | 0 | ALT3 | TxD1 | 28 | 198 | | | | 0v | | | 39 || 40 | 0 | ALT3 | RxD1 | 29 | 199 | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-Orange Pi+---+------+----------+-----+-----+ Is this 'glitch' in the output to be expected, for some reason, on my Orange Pi running Armbian?
  6. I am a long-time Linux user, who casually and confidently and regularly uses the software 'Update Manager' in Linux Mint to keep my software up-to-date. I also have no problem using 'apt update' to update specific software packages. What I am more careful about is ever using 'apt upgrade' and 'apt dist-upgrade' -- almost never doing so. What advise is there for updating the software on my Armbian Orange Pi PCs? darren@frodo10:~$ sudo apt list --upgradable Listing... Done armbian-config/stretch 5.45 all [upgradable from: 5.38] armbian-firmware/stretch 5.45 all [upgradable from: 5.38] tzdata/stable-updates 2018e-0+deb9u1 all [upgradable from: 2018d-0+deb9u1] Are these the packages that will be updated when I use 'apt upgrade'? Is this something that I should feel comfortable doing on a regular basis? Another related question is this: my current kernel version is this: 4.14.18-sunxi If and when newer kernels become available, will I be able to use an 'apt' command to install it? I am assuming that I will *not* need to download an entirely new 'image' and wipe out my existing install in order to gain the new kernel, right? Thanks!
  7. Wow! Compared to you, I am just a Time 'dabbler' -- and you are a Time 'master'! I spend $4 (or now even $10) on a PPS-enabled GPS module, and you (apparently) have spend hundreds of dollars on your stuff?! Please create a website showing off all your stuff, including photos of your equipment, so that people like me can be wowed So, just to be clear, in order to use the 'regular' version of NTP, you still had to compile from source yourself in order for PPS stuff to work? That is the impression that I have (i.e. that it needs to be 'patched') and so that is what I say on my web page. To answer your questions: My entries at the end of '/etc/ntp.conf' are: # Stats enable stats statistics loopstats statsdir /var/log/ntp/ filegen loopstats file loopstats type day link enable Make sure that you create the empty '/var/log/ntp' ahead of time, with the 'open' permissions, as mentioned on my page. I also have an entry in '/etc/rc.local' to re-create this on every re-boot: mkdir /var/log/ntp chmod 777 /var/log/ntp exit 0 Finally, in order to generate the graphs, I have a root-based 'cron' entry that calls a simple script -- which generates the graphs, and also transfers the directory to my webserver (rather than running a webserver on my Pi directly, I run the 'master' webserver on a Chromebook): #!/bin/bash cd /var/log/ntp /usr/local/bin/ntpviz -d /var/log/ntp -p 1 -n "Dare's NTP GPS/PPS Stratum 1 Timeserver Statistics Page" -w s -c /usr/bin/scp -r /var/log/ntp/ntpgraphs darren@frodo4:/tmp
  8. Look for the 'ntpsec' section on my page: http://darethehair.net/gps_time_server.html If you have the time, maybe also comment on whether you find anything in the Orange Pi section of this page confusing or incomplete One thing that I am confused about is whether or not the 'regular' NTP should be installed (or not) in order for the 'NTPsec' version to work properly. Hmmm... UPDATE: My two Orange Pi's with GPS are currently indoors, and unreliable for whether or not they can get a reliable GPS fix. As well, the temperature variations that occur when the heating goes on causes some fluctuations. So right now my NTPsec graphs are being driven by the statistics generated from my Raspberry Pi outside: http://darethehair.net/ntpgraphs/
  9. Bingo: Thanks for the tip that I needed to overcome my own obstacle (mentioned in post in this same subforum). I am curious where you got the info to add the 'param_pps_pin' parameter to '/boot/armbianEnv.txt'? After I did so, and rebooted, I finally got the '/dev/pps0' device required -- and my PPS time server now seems to be working! I cannot be certain at this point, but 'no', it does appear as though the default 'ntp' daemon that is available does not support PPS i.e. I got no entries at all for my server until I compiled/installed the 'ntpsec' package myself (the one that contains 'ntpmon', which I find useful to use). e.g. remote refid st t when poll reach delay offset jitter 127.127.1.0 .LOCL. 10 u 672 64 0 0.000 0.000 0.001 127.127.28.0 .GPS. 0 u - 16 0 0.000 0.000 0.000 o127.127.22.0 .PPS. 0 u 14 16 377 0.000 -0.063 0.098 *zero.gotroot.ca 30.114.5.31 2 u 9 64 17 38.907 1.213 39.990 -cloud1.pifts.ne 138.39.23.13 2 u 3 64 17 49.976 7.628 35.855 +james.kirk.hung 184.107.35.228 2 u 3 64 377 42.356 0.067 0.370 +mirror3.rafal.c 139.41.49.38 2 u 57 64 377 34.326 0.067 0.319 ntpd 4.2.8p10@1.3728-o Sun Feb 25 22:00:44 UTC 2018 (1)Updated: 2018-04-25T14:14:30 (8) lstint avgint rstr r m v count rport remote address 4 26 1d0 . 4 4 9 123 cloud1.pifts.net 4 45 1d0 . 4 4 16 123 174.142.39.145 (james.kirk.hungrycats.or 10 25 1d0 . 4 4 9 123 zero.gotroot.ca 58 44 1d0 . 4 4 15 123 mirror3.rafal.ca
  10. Yay! Thanks to a recent post by 'Bingo', I think I am able to deal with my PPS problem!
  11. UPDATE: Yesterday I (finally) got my 2nd Orange Pi PC Plus, and proceeded to install the latest Ambian 'mainline' image onto it: Armbian_5.38_Orangepipcplus_Debian_stretch_next_4.14.14.img My goal (as mentioned above) was to avoid -- if at all possible -- the need to re-compile the kernel in order to enable PPS for GPS accurate time tracking. From using 'armbian-config, I was easily able to do two things that I think were needed (and which were then added to '/boot/armbianEnv.txt': overlays=pps-gpio uart3 I wired up a GPS module, rebooted, managed to get GPSD working, but the PPS stuff doesn't (yet) seem to be according to 'dmesg': [ 8.283951] pps-gpio pps@0: failed to map GPIO to IRQ: -22 [ 8.283978] pps-gpio: probe of pps@0 failed with error -22 I also notice that ''/dev/pps0' is not present, so 'ppstest' won't work either. Any advise on what to do next? Do I have to edit/recompile a 'device tree' or something like that? There is a hint way back in 2016 that it might be required:
  12. BACKGROUND: Back on June 27th, I posted my questions regarding my wish to have certain kernel features activated (or not) by default in the Armbian/Debian kernels of the time -- specifically since I wanted to activate 'PPS' features in order to build a Stratum 1 GPS/PPS timeserver: Kernel Option Requests? Here are the 'old' instructions that I used back in June: ORANGE PI PLUS H3 with GPS/PPS I ended up needing to install VirtualBox with an Ubuntu 16.04 environment, and successfully created what I needed (i.e. 3.4.113-PPS-sun8i). I was also eager to create a much newer kernel, but that failed (i.e. 4.11.5). My Orange Pi PC Plus is successfully running at this much older 'legacy' kernel version my GPS/PPS NTP timeserver -- and nothing else. TODAY: I also have a Raspberry Pi 2 running Debian Stretch with FlightAware aircraft tracking. I had been recently forced to upgrade my system from Jessie to Stretch, and basically had to start all over again. It also runs a GPS/PPS timeserver -- and was much easier to implement since no kernel re-compilation was needed. FUTURE: I would like to *combine* a regular/standard Debian Stretch environment (running FlightAware) *and* a GPS/PPS NTP timeserver on my Orange Pi PC Plus (instead of my Raspberry Pi 2). However, the name/arrangement of the kernel options I think I need (PPS/PTP/Tick-based) have changed locations in the 'make' process. Not only that, but it appears to me that the options that I want are now *default* in the kernel (!). Is this true? Here are the menu options I pick and see: Select what to build Full OS image for flashing Select the kernel configuration Show a kernel configuration menu before compilation Select the target board. Displaying: - Officially supported boards orangepipcplus H3 quad core 1GB RAM WiFi eMMC Select the target kernel branch Exact kernel versions depend on selected board next Mainline (@kernel.org) (4.x) Select the target OS release stretch Debian 9 Stretch Select the target image type Image with console interface (server) Device Drivers ---> -*- PPS support ---> --- PPS support [ ] PPS debugging messages *** PPS clients support *** < > Kernel timer client (Testing client, use for debug) < > PPS line discipline < > Parallel port PPS client <M> PPS client using GPIO *** PPS generators support *** Device Drivers ---> <*> PTP clock support < > Driver for the National Semiconductor DP83640 PHYTER General setup ---> CPU/Task time and stats accounting ---> Cputime accounting (Simple tick based cputime accounting) ---> (X) Simple tick based cputime accounting ( ) Full dynticks CPU time accounting I definitely need 'PPS' stuff, but the kernel option seems to show it is 'default' now. I don't think I need 'PTP', but it also seems to be default. Finally, I am supposed to disable a 'tickless' kernel, and a 'tick' one also seems to be the default (?). With this in mind, can I just take one of recent nightly Armbian/Debian Stretch images and forget about kernel compiling from now on e.g. Armbian_5.38_Orangepipcplus_Debian_stretch_next_4.14.14? Are these images supposed to be ones that boot and run successfully -- or are they totally hit-and-miss and at-my-own risk? If they are not 'safe', then what are my options for the creation of a Debian Stretch environment that will support my desired uses and configuration? Thanks for any confirmation/advise you can give me -- I have been using Linux for many years -- and built my own kernels years ago -- but this is a whole new level of learning and complexity for me to understand Dare P.S. Does '4.x' imply Debian Stretch? If so, what is the difference between: default Vendor provided / legacy (3.4.x - 4.4.x) next Mainline (@kernel.org) (4.x) dev Development version (4.x) I am assuming that what I want is the middle one i.e. "next Mainline (@kernel.org) (4.x)"
  13. I also have no success with 'chrony', including the problem you describe. However, I have had great success with a PPS-enabled 'ntp' on both an RPi and now an OPi. Yes, I am still determined to make 'chrony' work (since so many sites seem to prefer it), but I guess it is going to take a bit more work...
  14. Good to know! That clears my last question before going ahead of purchasing one (plus power supply/case) from FastTech (matches lowest price I can find, and I think includes faster shipping)...
  15. So, then, it is a hardware limitation rather than a software one, at least in the case of the CHIP? What confuses me is that the R Pi (I think) is similar, but there is a boot setting that suppresses console messages on the serial port -- so programs like GPSD don't get confused by extraneous stuff -- at least that is how I eventually got a GPS working on my R Pi (but not CHIP). Yes, I can see the advantage of multiple serial ports on Pi devices
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines