@Nagarjuna-Reddy I can't test this right now, but first I think you need to remove the sdcard module as it will likely be managing the registers:
Then I expect you can use the GPIO like so:
gpioctl dirout-high 22
gpioctl get 22
gpioctl dirout-low 22
gpioctl get 22
@jonty So your server is now bound correctly, so now look at the client. Did you update the client code to use the specific port 9090?
lsof is not installed by default, you need to install it:
opkg install lsof
If this fails then you need to update your distfeeds. Edit /etc/opkg/distfeeds.conf uncomment lines 2 and 5. Run opkg update; opkg install lsof
But since your server will now bind correctly you don't need lsof
@danilo-burdese hi plz use below method for making a PPP internet purpose.
step1: opkg update
opkg install chat comgt
Step2: vi /etc/config/network
config interface 'hologram'
option defaultroute 1
option device /dev/ttyS1
option apn jionet //jionet place use your network apn
option service umts
option proto 3g
option 'pppd_options' 'noipdefault'
Step3: vi /etc/config/firewall
this you have to copy config forwarding above line.
option name 'cellular'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'hologram'
option input 'ACCEPT'
Step4: /etc/init.d/firewall restart
Step5: /etc/init.d/network restart
that's it thank you.
@supczinskib Sorry for the delay, been working on another project. I managed to get ssl to work with the device and tested out a lot of the configuration options. I had an issue with the example and posted it along with a solution in another thread -> Setting up ssl/tls with mosquitto = "A TLS error occured" solution. Hope this answers your question.
@Andriy-Malyshenko You can download OpenWrt 19.07.5 from the OpenWrt site:
You don't get some of the Onion developed components but you can always install those yourself.
For a "just monitoring" device it could not have any trouble once the ECU do the great of the processing activities before transferring data to/from CAN. So, would be possible to translate DTC Codes to a more friendly languages, define some alerts (eg.: out of safe range of AFR, engine temp as too hot/cold, some other relevant pressures), even some additional resources like calculations to give hints like shift up/down.
For a piggyback use, probably would need an "special order" dock by having some more modules, once would need a more real time processing, fast enough to convert data on-the-fly and do the ECU read this new data to make you need (like "aftermarket" turbocharged, supercharged or even with nitrous vehicles).
For a standalone EMS, it's really a topic for more engineering capable people, once it demands an amount of modules and controllers. And, unfortunately is not my case considering time and health conditions.
So my focus tends to be restricted to a "monitor" device only.
@Alberto-Brosich This is a nice article on debugging wifi issues:
The log should give you more information about what is going on.
If you are associated but not getting an IP it may be an issue with your dhcp client, to confirm this set the proto to static and hard code the ip. After restarting the network see if you can ping your network router and 188.8.131.52 (google dns)
The results of this will provide more info as to where your issue may lie.
@MickPF This depends on how you are doing your development. New players often start off doing some development on their Omega2x device, eventually, you realise this a short term solution since IoT devices are by design resource poor.
The best way to do Omega2x development is to install the build system https://github.com/OnionIoT/source then you will have access to everything you need as well as the cross compiler, so you can use your more powerful desktop/notebook device for your development and then move the completed work to your Omega via scp/ftp.
The headers and libraries you are looking for are on the Onion Github,
Also refer to the docs on how to compile on the Omega: