@austin-Sandford not entirely. I was able to get it to read and write to RTC but not the eeprom or get temperature. I changed line 25 from i2c-1
ds3231 = SDL_DS3231.SDL_DS3231(1, 0x68)
to i2c-0
ds3231 = SDL_DS3231.SDL_DS3231(0, 0x68)
@austin-Sandford not entirely. I was able to get it to read and write to RTC but not the eeprom or get temperature. I changed line 25 from i2c-1
ds3231 = SDL_DS3231.SDL_DS3231(1, 0x68)
to i2c-0
ds3231 = SDL_DS3231.SDL_DS3231(0, 0x68)
I use 2 methods:
from result of both I could tell if I needed to call wifimanager to restart. Since b17* it's been stable enough to reconnect itself so I no longer use this and I cache data until I am able to connect again using urllib2.
Taking it to the next level:
This is my travelling demo unit I am working on. I added a Pi driven touch screen to the mix to allow for operator interaction with mysql in the onion via the onion AP, access control granted via a nifty little serial fingerprint scanner (can run on either pi or onion), barcode scanner and a little "closed loop machine demo" which contains 2 servo's and a microswitch that I still need to complete. It's come a long way since the veroboard prototype days!
@James-Seigel I am based in South Africa and buy a lot of the new arrival chips and modules to play with from this company:
https://www.robotics.org.za/YK-E1007
I am not sure if Micro Robotics could ship internationally but sure they can help you locate a local supplier. I ordered one from banggood.com in china but it hasn't been delivered yet after 3 months of waiting
I was recently asked if I could add a barcode scanner to one of my IoT machine projects to help capture batch numbers while a manufacturing process runs. I found this awesome little scanner at my local supplier for just under $12.00 and was surprised at the simplcity of the interface and how quickly it all came together in an afternoon. The addition was so quick and painless I thought I would share my experiences with the community!
http://www.chinayoko.com/index.php?m=Product&a=show&id=134&l=en
A simple 3D printed mounting to house the scanner, buzzer and successful scan LED...
A couple of discrete components to level shift and drive the scan control...
And some simple serial port python code...
Now having tons of fun scanning everything within reach to test the prototype!
From personal experience on my IoT project with the arduino dock 2 and I2C - leave A4 and A5 open circuit on the dock - weird yes but if you add any I/O to them the I2C stops dead in it's tracks. Once you get it working pay attention to the I2C buffer in the arduino - clear it often as it fills up quick and starts responding 0xff to any and every query.
Articles like this one helped me a lot: https://onion.io/2bt-digging-into-i2cget-and-i2cset/
Before going through the hassle of a factory reset and starting again there is another quick and simple way to get your wifi working:
https://docs.onion.io/omega2-docs/first-time-setup-command-line.html
Running the console after that is quite a bit faster
It's been a while since the last update but I wanted to show off the cute 3D printed case I designed for my device...
And here's a sneaky cell phone image of one out in the wild looking after monster of a machine...
I've managed to sell the entire first batch of boards - quite happy about that! I'm now busy working on a second generation that adds a few more nifty features as well as correcting a few quirks in the original design. Despite initial concerns and a lot of grey hair, the omega is turning out to be a reliable little device. Thanks again to the community for all the tips and assistance given! Onioneers rock!
@michael-bourque thanks for that! I left the device alone for a couple of weeks and then updated to b183 - it is now stable and connecting to wifi on it's own like it should. I am not going to use it on my production devices yet though - still need to put it through it's paces but I think all will be ok going forward!
As for the wireless config file reset, on the very first boot, the new OS will look for traces of the old wireless configuration, and if found, will reset the config.
It's possible that you still have programs installed that write old wireless configuration, try running the following:opkg update opkg remove wifi-manager opkg upgrade onion-console-base
Hasn't helped at all - if I leave it off for a couple of days it connects once but after reboot it won't connect again. It continues to show up in the router dhcp list long after it is switched off too. None of the other 7 onions i have currently running b160 do that - session is dropped after a minute of being powered down. There is no difference in boot log with either ethernet board in or removed yet with ethernet board in the wifi works perfectly:
[ 26.878280] Onion Enhanced MT7688 WiFi Driver
[ 26.878280]
[ 27.084718] DMA Scheduler Mode=0(LMAC)
[ 27.088552] efuse_probe: efuse = 10000012
[ 27.092693] 1. Phy Mode = 14
[ 27.264897] 2. Phy Mode = 14
[ 27.267875] 3. Phy Mode = 14
[ 27.275215] WTBL Segment 1 info:
[ 27.278588] MemBaseAddr/FID:0x28000/0
[ 27.282476] EntrySize/Cnt:32/128
[ 27.285964] WTBL Segment 2 info:
[ 27.289325] MemBaseAddr/FID:0x40000/0
[ 27.293208] EntrySize/Cnt:64/128
[ 27.296665] WTBL Segment 3 info:
[ 27.300025] MemBaseAddr/FID:0x42000/64
[ 27.303997] EntrySize/Cnt:64/128
[ 27.307455] WTBL Segment 4 info:
[ 27.310815] MemBaseAddr/FID:0x44000/128
[ 27.314886] EntrySize/Cnt:32/128
[ 35.795856] device ra0 entered promiscuous mode
[ 35.800605] br-wlan: port 1(ra0) entered forwarding state
[ 35.806196] br-wlan: port 1(ra0) entered forwarding state
[ 35.813460] IPv6: ADDRCONF(NETDEV_CHANGE): br-wlan: link becomes ready
[ 37.804640] br-wlan: port 1(ra0) entered forwarding state
[ 54.194658] random: nonblocking pool is initialized
First attempt at installing has turned into a dismal failure. All worked fine up until I started creating overlay SD card then it stopped connecting to wifi after a reboot. Tried reinstall from scratch but now it won't connect to wifi at all and i can't revert to 0.160. Have noted that on reboot /etc/config/wireless loses the wifisetup and everytime I connect to the AP putty says it has a new certificate. ifconfig says:
apcli0 Link encap:Ethernet HWaddr 40:A3:6B:C1:C8:88
inet6 addr: fe80::42a3:6bff:fec1:c888/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
On other devices running 0.160 there is an IP address from my router:
inet addr:192.168.14.25 Bcast:192.168.14.255 Mask:255.255.255.0
Also worth noting is that the mac address in aplci0 is C8:88 whilst the chip is labeled as C8:87. This has also changed since.
I am now stuck with no wifi - what has changed? what am I missing?
UPDATE: Completed my SD card installation with python, mysql etc using an ethernet board - wireless came back online after a couple of reboots and remained stable for about 30 minutes then a subsequent reboot reset the wireless conf file again
@Gyรถrgy-Farkas said in Restarting I2C without reboot:
What does this mean precisely? (For example this "the I2C port locks up" ???)
Simplified Software flow:
while True:
size = 1
addr = 0x0E ## this is my control register - set to 1 when arduino has data to share
update_flag = i2c.readBytes(devAddres, addr, size)
if update_flag[0] > 0 or first_run_flag > 0:
first_run_flag = 0
addr = 0x20
counter_1_val = i2c.readBytes(devAddres, addr, size)
... then i read through a whole bunch of other data registers and write to sql db. Once the last register is read then the arduino clears the update flag and we cycle through every 300ms or so
This runs perfectly for many hours and then no matter which register is read i still get the last value of the last register read no matter which address i get or set. Nothing is sent to the arduino on the i2c bus but there is still a response on the i2c.readBytes() function.
At this point even i2cset and i2cget return the same value as python call does. Resetting the arduino at this time does not help either
This only happens with the arduino dock address 0x08 - the oled and RTC still work fine.
Can anyone suggest a way to reset the onion I2C without rebooting? <-- i would like to restart /dev/i2c-0 to see if this module is stuck
A lot of grey hair and some worry about the reliabilty of my product...
@Dwayne-King I use your grep method on ifconfig every 10 minutes to look for the presence of apcli0 and a partial match to 'inet addr:192.168.' - if not found I call wifimanager. Works well for me as I have a list of over 40 possible access points in 192.168.. range while my devices travel
@Gyรถrgy-Farkas said in Restarting I2C without reboot:
IoT ONE board or a genuine Arduino Dock 2?
My IoT ONE board contains a genuine arduino dock 2. This happens when running the dock standalone too. The sketch is running fine as I am watching regular data updates on it's serial port which shows that it stops receiving any i2c request from the omega when this fault occurs
@brolly759 I have additional pullups as well through the level shifting circuit. It's not likely to be hardware as the RTC and OLED still update fine
I am struggling with a error on the arduino dock 2 where after a couple of hours of flawless communication between onion and arduino, the I2C port locks up and returns a random single value between 0x63 and 0x99 for any command value sent without sending anything out on the port.
In short - onion says it's receiving a value but there is no further comms between it and the dock. This happens with both python and using i2cset/i2cget and it only affects the dock - other I2C devices keep functioning.
The only way I have managed so far to recover from this is to reboot which is not ideal as it resets the arduino as well. I do not know enough about how the drivers are loaded - Can anyone suggest a way to reset the onion I2C without rebooting?
@brolly759 The SMD version was released about 2 weeks after I had designed my boards! :))
Heres the last part of the system I haven't documented: 4 port Pi Zero hub & bareboard 720p cameras. The arduino dock powers all 3 cameras without issue
@Douglas-Kryder It's an adjustable LM2596 power supply module DC/DC BUCK 3A which I purchase from a local supplier for a lot cheaper than the raw LM2596 chip would cost on it's own.
Here's a clearer photo...