hmartin
-
Posts
67 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by hmartin
-
-
The advertisement can be found here: http://www.orangepi.org/orangepizero, look for "What can I do with Orange Pi Zero". One of the bullet points is "wireless server". I think an AP qualifies as a "wireless server".
Show me where on that page is says "AP"
A wireless server can be any computer connected via WiFi which exchanges data. e.g. it's connected as a client and runs an HTTP server where you can download files.
Boom! Wireless. Server.
I also almost made a donation and glad now I haven't !
So you won't donate to us, volunteers who spend our own time and money to buy the hardware and improve it, because we didn't make a perfect product that can do everything you dream of?
Now wouldn't it be nice to have a FAQ upfront on Armbian homepage to clear up all this confusion, updated monthly?
But you guys are happy instead spending 80% of your time on repair jobs. Where is the innovation?
If people like you didn't complain so much, we might actually have the time and motivation to do "innovation"
This is the n'th time you've suggested that we take even more time away from "innovation" to create an FAQ for lazy people like you who can't be bothered to read the forum or mailing list.
I will again suggest that you can spend your own time making the monthly FAQ, instead of posting complaints on the forum about how we don't follow your every suggestion.
@pacifica
I actually meant looking at comments on both articles at cnxsoft than the article itself .... It tells you how much respect certain Armbians get trying to answer questions or attempting to abuse others, at more open forums.
That is the fun part here. Folks here call everything crap, but keep working on it too !
Why?
Excuse me? Our answers are 'abusing' you?
Please. Get a grip. We're the ones actually improving the features you all are using, and what do we get? You publicly congratulating yourself for not donating money to the cause and complaining that it doesn't work.
Why do we work on this at all? Maybe because we bought the hardware, realized that it has limitations, and are working to improve it for our own use. We could certainly improve it and keep the improvements to ourselves. We're not selling a product, we're not required to push our patches upstream.
Unlike you, I don't go to internet forums of open source projects and whine that my expectations weren't immediately satisfied. I'm actually trying to improve things to the point where your completely unrealistic expectations ARE realized.
Armbian wouldn't need many contributors and certainly would have much less arguments/confusion if you guys don't spend 80% of your time on repair jobs and insulting folks as opposed to having a decent FAQ and asking, say OPi, to do eMMC on OPi0 as well, a better WiFi job etc.
At least acknowledge the facts: is above any innovation, or even a positive attitude?
- If you want to see "innovation" go use the Debian image from Xunlong: http://www.orangepi.org/downloadresources/
- Do your own research before buying. You're presumably an adult, it's not our job to educate you before you spend money. We're able to spot marketing bullshit before buying, and adjust our expectations accordingly. I'd suggest you file this under a "learning experience" that not everything the salesmen tell you is true. At $10, it's a pretty cheap life lesson.
- We'd have a much better attitude if people like you didn't show up to lecture us on how we should be "innovating" more. The best thing you personally can do for innovation right now, is put away your Orange Pi Zero, stop posting stupid missives like the one above, and come back in 6 months.
-
Thanks for the tip, borombo, but my application already uses the USB for a flash drive for expanded storage.
There's 2 additional USB ports available from the expansion header. You'll need a 2.54mm to USB-A female adapter. Something like this would work (with the pins re-arranged appropriately).
Alternatively, Xunlong sells an expansion board for the Orange Pi Zero which adds two USB ports, microphone, IR, and audio/video out.
I have a Rpi3 set up about the same as the OPi0, and when I connect it up I get the full 30. Each time I've tested with the OPi and RPi, my phone is the only device connected.
Say what you will about the Raspberry Pi foundation, but their hardware support is pretty good. This is a case of "you get what you pay for"
-
What to do with the pollution of this thread (whining and support questions)?
I won't be working on the cw1200 mainline driver anymore. From my conversations with dgp, even if I did modify it enough to work with the cw1160 in the Orange Pi Zero, performance would be as crap as Allwinner's driver from the SDK.
So let's lock the thread and people discovering the shitty performance can go complain in Orangepi forums.
-
I don't think anyone would accept flipping 0.000001% of the bits in memory, not even for a cheap board ;-)
First off, this happens on x86. Google "rowhammer" if you think that this kind of situation isn't a problem even for "expensive" computers.
It may be true that the board is cheap, however I think it's reasonable to expect that it works as advertised (which includes using it as an AP).
Xunlong never advertised the Orange Pi Zero as an AP! Please, show me where they said "use the Orange Pi Zero as a WiFi router"
Even the cheapest WiFi routers that I know of cost $15 (AR9331/MT7620).
This is additional functionality that we've been lucky to get from the WiFi radio, and now people are getting all pissed that it doesn't work as well as a Raspberry Pi.
In my country, the Orange Pi Zero costs as much as a hamburger meal from McDonalds. Just try and use your hamburger as an AP...
Fack, people. Lower your expectations.
-
I take issue with companies that are developing and selling these hardware products and expecting the users to fend for themselves on the software side. At least provide some form of operating system, or a ready-made Linux distro ISO that actually works. I have no idea how long until the wifi driver will actually be fixed. Note, that mainly is aimed for the maker of this board, I take no issues with the people of armbian, they're good people
Then vote with your wallet and buy a Raspberry Pi or ODROID.
I'm sorry but people who spend the absolute minimum on a board and then expect it to have the same level of community and support as the Raspberry Pi are the problem, not the companies making them.
Adjust your expectations accordingly. You paid <$10 for this board. Don't expect a perfect product for that price.
Perhaps, but right now I'd settle for a small miracle of reliable connections, which I'm guessing isn't happening based on the large number of a fore mentioned tx retries.
I haven't noticed too many problems using TCP. If the packet is dropped, TCP will handle delivery. UDP and other protocols which don't handle retransmission are not recommended at the moment.
-
I've set up my new OPi Zero as a wireless AP running the latest Armbian build for the OPi0. It's working mostly great. My one problem I'm having is that my speeds seem to be throttled to 5-6Mbps. I connect wirelessly from my phone and run a speed test and get 5-6Mbps. If I connect directly to my router, I get 30Mbps.
Yes, the XRADIO driver is crap. This has been known for quite some time. If you want good WiFi performance, don't use an Orange Pi Zero.
See here for further discussion of WiFi performance:
https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-xradio-st-cw1200/?p=22863
Summary:
Single antenna low power Wi-Fi in 2.4 GHz band is great to send some sensor data around but please don't expect 'throughput' with this 'as cheap as possible' type of wireless device.
The best I got with el cheapo Wi-Fi (tested with OPi Lite, Banana Pro, Pine64 and NanoPi Air) here in my place was 20 Mbits/sec over a pretty short distance using a good AP configured to use highest power profile. At night! During the day and especially in the evening when loads of other devices around utilize the same radio channels bandwidth drops down to laughable numbers and latency increases like hell.
BTW: 20 Mbits/secs means not even 3 MB/s! Just to be sure... I'm always surprised about the huge amount of confusion around Wi-Fi: people thinking there would be something like 'guaranteed bandwidth', hiding SSID would improve security, same with MAC filter... all plain BS but a lot of people believe in
-
so I would love to have a Orange Pi Zero with improved wifi drivers.
We would all like better WiFi drivers. Unfortunately, all we have right now is what we got from ST-E/Allwinner and it's not very good.
Is it possible to install your version of the drivers already? (52MBit/s in average seems quite good in comparison)
- 52MBit/s is the PHY data rate, not the download speed. I'm getting at most 10MBit/s in testing (less than 1m from AP).
- The driver in use is xradio and can be built against the kernel sources (e.g. 4.9) so you have WiFi. Get it here: https://github.com/fifteenhex/xradio
- My modifications to the mainline cw1200 driver are enough to initialize the hardware, but the WiFi chip crashes when you try to scan or join a network.
Since the cw1200 module in the kernel is almost identical to the driver from the Allwinner SDK, this means even if it worked with the XR819 (which it doesn't) the performance would be just as bad.
Honestly not sure why a driver for pre-production silicon with crap performance ever made it into mainline, but whatever...
Would the very great if you could do this, because I'm not able to do this...
We are working to improve the driver, but please realize:
- We have no datasheet from Allwinner on how it's supposed to work
- None of us are paid to do this
- We all have normal lives with jobs and shit that take up lots of time
So please be patient, and don't ask us when it will be finished. If you need a board with good WiFi, then that is not the Orange Pi Zero.
If you want to help, get Allwinner to release the datasheet so we don't have to guess how this thing works.
-
You have made the same mistake graphically that I made physically at first. Sorry for not being clear enough.
In that picture, you have actually encircled R353/R352. These are _not_ identical to R135/R136. R135/R136 sit directly below the encircled resistors in that picture. R353/R352 can stay, R135/R136 have to go.
Whoops, thanks for the correction!
-
"Eventually..."????
You're welcome to submit a u-boot patch to support it faster.
-
I see.... this is beyond me and needs and expert touch and a lot of time. I have to live with SD card. Can you or someone else recommend me reliable SD card brand except usual suspects Kingston and Scandisk...Something else?
Wait a bit more. SPI support will come in u-boot eventually.
I use Samsung EVO/EVO+ and never have any issues. I don't buy Sandisk anymore since their cards are under capacity.
So do I need to dig through WiringOP or did I do something wrong? I really need GPIO support form my IoT software handling multiple sensors connected via modbus rs485 etc.
For RS-485 won't you need a level shifter anyway? e.g. http://www.robotshop.com/en/sfe-uart-to-rs-485-converter.html
Why not just use a USB to RS-485 adapter? China has them for under $5, which is probably less than you will pay for a level shifter + breakout board.
-
These resistors can be found on the top side of the board, next to the RJ45 jack:
(Apparently I'm not allowed to post images. Be sure to remove the correct ones. the resistors nearest the label "R135/R136"l are actually R353/R352. R135/136 are nearer to the RJ45 connector. Yes I found out by removing the wrong ones first.)
If these resistors are left on the board, they will connect POE+ and POE-GND with a resistance of 150Ω. At 24V, that would produce 3.8W of heat. These resistors would not sustain that. I found out something's wrong in the good old tradition of connecting power and see if smoke develops.
Thanks for pointing this out! Sorry it was missed in the summary of PoE options.
I've updated the wiki with instructions to remove the resistors and a photo highlighting their location on the PCB.
-
Are you able to get data like the number of retries etc from the AP to the orangepi?
In iw wlan0 station dump on my hostapd based access point (totally different hardware) I can see a lot of TX retries for the orange pi client. A lot more than an of the other connected clients.
My AP is running OpenWrt, and I see lots of tx retries for the Orange Pi Zero:
Station dc:44:6d:c0:ff:ee (on wlan0) inactive time: 10 ms rx bytes: 392890748 rx packets: 254433 tx bytes: 10862247 tx packets: 126252 tx retries: 112285 tx failed: 0 signal: -17 [-20, -20] dBm signal avg: -16 [-19, -19] dBm tx bitrate: 65.0 MBit/s MCS 7 rx bitrate: 26.0 MBit/s MCS 3 authorized: yes authenticated: yes preamble: short WMM/WME: yes MFP: no TDLS peer: no
-
I'm not sure where the performance bottleneck with the current driver is. $iw dev wlan0 station dump; says it thinks the throughput should be ~13-20mbps and that's what I seem to get when scp'ing a file but it also does start out twice as fast before settling at that speed. So I wonder if we are actually failing to transmit frames at the higher rates and the rates are being adjusted down correctly or if what the driver is reporting to mac80211 isn't right and the rates are being lowered incorrectly.
I checked on my router while I was doing my performance testing. The PHY was running as high as MCS 7 (65MBit with 20MHz channel @ 1T1R), and averaged around MCS 5 (52MBit) between the Orange Pi Zero and the AP. These are readings from the AP, not the Orange Pi Zero, so I'm fairly sure they're accurately reflecting the true state of the xradio PHY.
Nothing was CPU-bound, yet I was still only getting 10MBit/sec with iperf. This was at less than 1m away from the AP, signal is at -14dBm and noise is -95dBm.
Then again I normally use 5GHz because 2.4GHz is such a shit show in my building with all the neighbours' APs.
-
On the CW1200 driver: Someone tried to submit patches to make it work better in the past. It seems almost none of those patches got applied so the mainline driver is still roughly a source dump from ST. From what I can tell it has the same issues as the XR819 driver (locking up the kernel if things start go wrong etc). Apparently no one uses it as no one replied to my mail on the linux-wireless mailing list about it and the only patches it's seen recently are low hanging fruit from static code analysis tools.
IMHO we should try to improve the XR819 driver for now. Get it down to as little code as possible. I think there are places that can be replaced with stuff that's already in the kernel like the queue for TX packets.
Thanks for the feedback. I agree on improving the XR819 driver. I was hoping that the cw1200 driver would bring some performance improvements since it's already in mainline, but it seems it's the same kludge as what we got from Allwinner. I guess when no one else is using the hardware the kludge never gets cleaned up. The reference driver checks the WORKSFORME box and moves on.
Were the patches to cw1200 of any use for the XRADIO improvements?
-
I got the cw1200 module to load on the xr819. There were two issues:
- Sending a NOP
- Setting DPLL to the wrong frequency, apparently this caused the bootloader not to respond (not sure why exactly, maybe DPLL effects SDIO speed?)
[ 26.003305] cw1200_wlan_sdio: Probe called [ 26.007933] silicon_vers: 0 [ 26.010731] HIF_8601_SILICON [ 26.057552] Set DPLL to: 0x00000141. [ 26.107539] WLAN device is ready. [ 26.110851] CW1x60 silicon detected. [ 26.136517] Bootloader complete [ 26.139693] Detected CW1160/1260. [ 26.143210] CPU released from RESET [ 26.152946] Bootloader reported ready after 0 [ 26.226567] Firmware download completed. [ 26.240724] CW1200 WSM init done. [ 26.240724] Input buffers: 30 x 1632 bytes [ 26.240724] Hardware: 7.9 [ 26.240724] WSM firmware [XR_C01.08.0043 Jun 6 2016 20:41:04], ver: 8, build: 43, api: 1060, cap: 0x0003 [ 26.316284] Registered as 'phy0'
Unfortunately if you try to actually do anything with the WiFi, the firmware crashes due to differences between the sdd file and the running configuration. I've tried both the Allwinner sdd_xr819.bin and sdd_sagrad_1091_1098.bin and neither seem to like what I'm doing.
[ 184.358242] SDD file doesn't match configured refclk (24000 vs 38400) [ 184.442816] ieee80211 phy0: Firmware assert at syn_start.c, line 2001 [ 184.449258] ieee80211 phy0: R0: 0x00014080, R1: 0x000007D1, R2: 0x00002711, R3: 0x040088D8, [ 184.457621] ieee80211 phy0: R4: 0x040088D8, R5: 0x04003E88, R6: 0x04003E70, R7: 0x00000000, [ 184.465983] ieee80211 phy0: R8: 0x4C68E107, R9: 0x37A37ED1, R10: 0x42209403, R11: 0x040814CA, [ 184.474519] ieee80211 phy0: R12: 0x0000A7C3, SP: 0x0400B668, LR: 0x00013F9D, PC: 0x00013F99, [ 184.482960] ieee80211 phy0: CPSR: 0x0000001F, SPSR: 0x000000DF [ 184.488790] R1: 73 79 6e 5f 73 74 61 72 74 2e 63 00 70 3e 00 04 syn_start.c.p>.. [ 184.488794] R1: 50 36 00 04 88 8a 00 04 c0 93 00 04 01 80 00 00 P6.............. [ 184.488798] R1: 40 0d 03 00 34 8e 00 04 68 4a 00 00 10 27 00 00 @...4...hJ...'.. [ 184.488855] [BH] Fatal error, exiting.
I guess the next question is whether the cw1200 driver in mainline is any good or not. In my performance tests I'm getting around 10Mbit/s down/up (unidirectional testing only) using iperf on the XR819 driver:
Download[ ID] Interval Transfer Bandwidth[ 4] 0.0-400.0 sec 512 MBytes 10.7 Mbits/secUpload[ ID] Interval Transfer Bandwidth[ 3] 0.0-379.4 sec 512 MBytes 11.3 Mbits/secIt doesn't seem that the cw1200 module works with any final revision silicon, as evidenced by this from the module source: pr_err("Can't handle CW1160/1260 firmware load yet.\n");Edit: You can do insmod cw1200_core.ko cw1200_refclk=24000 to override the default refclk, which will get rid of the SDD error above. Unfortunately the firmware still crashes if you try to do anything. -
I've confirmed that the _10, _11, _20, and _22 files are for earlier hardware revisions:
if (ar1 == CW1200_CUT_22_ID_STR1 && ar2 == CW1200_CUT_22_ID_STR2 && ar3 == CW1200_CUT_22_ID_STR3) { pr_info("CW1x00 Cut 2.2 silicon detected.\n"); priv->hw_revision = CW1200_HW_REV_CUT22; } else { pr_info("CW1x00 Cut 2.0 silicon detected.\n"); priv->hw_revision = CW1200_HW_REV_CUT20; }So presumably these are files for development silicon (CUT 1.0, 1.1, 2.0, 2.2). I would hope that Allwinner didn't buy an incomplete design from ST.
-
Well, you can still find them: https://github.com/Evanok/snowball_builder/tree/master/firmware/cw1200
---
So in the end the chip accepts the bootloader but doesn't accept the firmware? And BTW mainline driver from @dgp doesn't suffer from bootloader issues - it's loaded correctly from the first try if I understand it correctly.
Nice find. These still appear to be for some other variants of the hardware, testing versions perhaps?
switch (priv->hw_revision) { case CW1200_HW_REV_CUT10: fw_path = FIRMWARE_CUT10; if (!priv->sdd_path) priv->sdd_path = SDD_FILE_10; break; case CW1200_HW_REV_CUT11: fw_path = FIRMWARE_CUT11; if (!priv->sdd_path) priv->sdd_path = SDD_FILE_11; break; case CW1200_HW_REV_CUT20: fw_path = FIRMWARE_CUT20; if (!priv->sdd_path) priv->sdd_path = SDD_FILE_20; break; case CW1200_HW_REV_CUT22: fw_path = FIRMWARE_CUT22; if (!priv->sdd_path) priv->sdd_path = SDD_FILE_22; break; case CW1X60_HW_REV: fw_path = FIRMWARE_CW1X60; if (!priv->sdd_path) priv->sdd_path = SDD_FILE_CW1X60; break; default: pr_err("Invalid silicon revision %d.\n", priv->hw_revision); return -EINVAL; }So in the end the chip accepts the bootloader but doesn't accept the firmware? And BTW mainline driver from @dgp doesn't suffer from bootloader issues - it's loaded correctly from the first try if I understand it correctly.
I'm comparing the cw1200 driver in mainline to the work from @dgp.
The cw1200_wlan_sdio init sequence sends the bootloader, but then the bootloader signals it's not in the right state to download the main firmware, and at this point the module stops trying to initialize the chip. For some reason the DOWNLOAD_STATUS_REG is returning DOWNLOAD_ERR_IMAGE instead of DOWNLOAD_PENDING.
...I just realized I could find the errors in hwio.h, so I guess I don't actually need a datasheet from ST to figure out what this error means.
I think I will add more debug statements to @dgp's xradio driver to see if I'm missing a setup step in the cw1200 init sequence.
-
Edit: I've found all sdd_xx.bin and wsm_xx.bin files, but still they are worthless without a working bootloader.
Yes, I was able to find wsm_22.bin as well, it's in linux-firmware. However if you look at fwio.h, there are way more firmware files for this driver:
#define BOOTLOADER_CW1X60 "boot_cw1x60.bin" #define FIRMWARE_CW1X60 "wsm_cw1x60.bin" #define FIRMWARE_CUT22 "wsm_22.bin" #define FIRMWARE_CUT20 "wsm_20.bin" #define FIRMWARE_CUT11 "wsm_11.bin" #define FIRMWARE_CUT10 "wsm_10.bin" #define SDD_FILE_CW1X60 "sdd_cw1x60.bin" #define SDD_FILE_22 "sdd_22.bin" #define SDD_FILE_20 "sdd_20.bin" #define SDD_FILE_11 "sdd_11.bin" #define SDD_FILE_10 "sdd_10.bin"
I guess these files were never released.
The wsm_##.bin and sdd_##.bin files seem to be for specific versions of the hardware. After changing the SDIO ID of the chip, the cw1200 driver is detecting the silicon as CW1X60_HW_REV and attempting to load boot_cw1x60.bin, sdd_cw1x60.bin, and wsm_cw1x60.bin.
If you do a hexdump on the boot_xr819.bin from Allwinner, it appears to be a loader for the rest of the firmware (wsm_*.bin files):
000008c0 72 65 64 0a 00 00 00 00 57 53 43 5f 4c 4f 41 44 |red.....WSC_LOAD| 000008d0 45 52 5f 46 57 5f 41 30 31 5f 30 30 5f 30 30 30 |ER_FW_A01_00_000| 000008e0 31 3a 41 75 67 20 31 39 20 32 30 31 35 2c 20 31 |1:Aug 19 2015, 1| 000008f0 38 3a 35 37 3a 35 31 3a 41 53 49 43 0a 00 00 00 |8:57:51:ASIC....| 00000900 28 20 70 7f |( p.|
Edit: I've found all sdd_xx.bin and wsm_xx.bin files, but still they are worthless without a working bootloader.
We do have a working bootloader, it's boot_xr819.bin from the Allwinner SDK.
I think source file license boilerplates are descriptive enough:
* Based on: * ST-Ericsson UMAC CW1200 driver, which is * Copyright (c) 2010, ST-Ericsson
Thanks, I'll just call up ST-Ericsson and ask them for their firmware reference manual
-
Hi everyone,
I was doing speed tests on the XR819 and started looking at the driver code. My this looks very similar to the cw1200 driver already in mainline Linux.
I started modifying the cw1200 driver to try and get it to work with the XR819. Apart from someone renaming functions and adding a bunch of important junk for XR819, the drivers are quite similar.
I've modified the cw1200 driver up to the point that it's loading the boot_cw1x60.bin ( boot_xr819.bin ) file, but for some reason the bootloader is returning an error instead of success. I don't think it's possible to diagnose this without the datasheet from ST.
Clearly this exists, because people were able to write the cw1200 driver for mainline. Does anyone have a clue where I might find the datasheet for the CW1100?
I also haven't been able to find the firmware files from ST for this chip. They don't exist in the linux-firmware tree!
Here's my progress thus far:
Try to load cw1200_wlan_sdio first time. Timeout waiting for bootloader to respond (I think XR819 has the same bug, no?)
[ 28.263492] cw1200_wlan_sdio: Probe called [ 28.357664] WLAN device is ready. [ 28.360985] CW1x60 silicon detected. [ 28.386731] Bootloader complete [ 28.389906] Can't handle CW1160/1260 firmware load yet. [ 28.395123] Fuck it, loading firmware anyway! [ 29.415376] Bootloader is not ready. [ 29.418990] Firmware load error. [ 29.422496] cw1200_wlan_sdio: probe of mmc1:0001:1 failed with error -110
Unload the module and load it again:
[ 78.093132] cw1200_wlan_sdio: Probe called [ 78.178590] WLAN device is ready. [ 78.181913] CW1x60 silicon detected. [ 78.205554] Bootloader complete [ 78.208727] Can't handle CW1160/1260 firmware load yet. [ 78.213944] Fuck it, loading firmware anyway! [ 78.219020] Bootloader reported ready after 0 [ 78.227529] Bootloader reported error 8. [ 78.231491] Firmware load error. [ 78.234973] cw1200_wlan_sdio: probe of mmc1:0001:1 failed with error -5
-
Btw, that monthly report is in the best time/effort interests of contributors themselves- less questions, more work.
Thanks for telling us what's in our best interest. And here I thought we were doing pretty well...
I am doing what my skill set allows me to do- I am neither a HW or SW guy, but have been and am a product manager. And I do see some product questions need to be asked here.
I'm not sure you understand how open source development works...
Sales: We're not selling anything, so we don't really need sales.
Product management: Since we're not selling anything, so we don't really need someone to stand on a soap box and tell us what to do.
Engineers: Design the hardware, write the software, write documentation for the hardware and software.
So if you want to help by writing documentation, or software, then we will welcome your contributions. But no one wants, needs, or asked for a product manager, so don't be surprised when we don't welcome this with open arms. I get enough of PM crap in my 9-5 job.
-
1. If I had the long term background of folks making significant volunteer contributions (cheers to all), I would volunteer too.
The other problem: as ex engineer, I know we are terrible at documentation anyway ( communication) so a lot of good work gets lost !
I'm an engineer by education and profession and somehow I manage to give useful answers to your questions.
2. You are exactly right. But you do realize asking questions is half the job? I didn't take credit for the edit. Merely said that listening with some patience can be productive.
You're right, how silly that I forgot the questions are the most important part of anything.
Who here wants to fix the XR819 WiFi driver so it doesn't suck?
Who wants to get it into mainline?
Whew, glad I asked these important questions so other people know what to do now.
In the end we got to admit some facts.
Yes, you are suggesting that we do extra work for you. You "suggest" that we write a monthly update, but won't spend your own time to do it.
You might find we're a bit more open to helping you if you contributed more than just questions.
-
May I suggest that Armbian forum post a monthly update with relevant links and a short summary so everyone is on the same page, as opposed to milling around different threads and getting confused?
Sounds great. When will you be publishing the first monthly update?
-
This 4 port injector https://www.amazon.com/WEONE-Ethernet-Injector-Ausr%C3%BCstung-IP-Kamera-CAT-5-6/dp/B01HPLCLGM/mentions a "resettable 650 mA fuse" for each port. I ask myself if 650mA is low enough for safety, and if this ability to reset itself is not risky.
Fuses are a good idea, but we're talking about 24V here. Enough to make a spark if you've got a big enough source (e.g. car battery) but in low currents it should be entirely safe to use.
650mA * 24V is 15.5W, which is the same limit as normal 802.3af. If they are not a one-time fuse, I would guess they're a polyfuse, meaning they are heat activated. The same kind of fuses are used to protect USB ports from over current.
However looking at the photos on Amazon, I can't see these fuses anywhere. If you buy this injector I would verify that there are actually fuses installed.
I guess I should add an additional external fuse between power supply and PoE injector that is even lower for peace of mind. 4 Opi0s, with IoT power saving settings but both network interfaces active, might consume 3 Watt total. With 90% efficiency of the buck converters I would need 3.3 Watts total at the 4 remote network sockets, Wikipedia tells me PoE specs assume ~25% conduction loss, so I would need to inject 4.2 Watts total into the central patch panel, which at 24 Volts means total current for 4 Opi0s should not exceed 175mA.
If I use a single external 200mA quick melting fuse for a four port injector I should have enough power to drive 4 Opi0s and still have headroom for spikes. My cat6 installation length is < 20m everywhere. With the normally low currents of the Opi0s, conduction loss should be lower than the 25% rule of thumb for PoE.
200mA * 24V is only 5W. In my opinion this is cutting it too close, you're very likely to have the fuse burned out at some point due to a current spike (e.g. if you have a power failure and all Orange Pi Zero's restart at the same time). I also think that 3W for 4 Orange Pi units with Ethernet and WiFi is too conservative.
I would recommend using a larger fuse. Something around 1A (24W) will provide both enough head room for all Orange Pi Zero units to run and yet still provide the protection you're seeking.
24W won't generate enough heat to cause a fire, even if there's a direct short.
-
Good explanation. Your link , "Stages of powering..." comes empty.
Works for me, but here's the raw link:
https://en.wikipedia.org/wiki/Power_over_Ethernet#Powering_devices
In which case the OPi0 linux-sunxi description should be amended to remove references to 802.3af capabilities ( power splitters can be used in all feed cases anyway.) OPi0 is just a passive PoE PD.
I have updated the page based on our discussion!
Orange Pi Zero went to the market
in Orange Pi Zero
Posted
OpenWrt is far more suited to industrial environments. Most OpenWrt hardware uses NOR flash, which does not degrade via reads, NAND does.
Wikipedia has more details on this: https://en.wikipedia.org/wiki/Flash_memory#Read_disturb
You can even buy OpenWrt devices which use NAND, if you need more storage. These routers have more than enough horse power for almost any M2M application, and you can buy them pretty cheap: https://www.aliexpress.com/item/Original-Xiaomi-WIFI-Router-3-WiFi-Repeater-1167Mbps-2-4G-5GHz-ROM-128MB-Wi-Fi-Roteador/32688259842.html
Supporting Linux on these cheap SBCs is not a total waste of time, but it might be for your use case.
Yes, you absolutely need to buy multiple boards and test them for your use case. Or you can call a distributor like Digikey and ask them for the right board for your application. You will pay a lot more for this, it won't be as new as the Orange Pi Zero, it will probably use some vendor proprietary toolchain and Linux image, but it will work for 10 years and your customers won't hate your product because you thought it would be good to build it around a $10 SBC from China.
No one is saying you can expect stability from an Orange Pi Zero for your use case. You need to test it yourself and figure out whether it's stable or not. We don't have the resources to test the hardware in your use case.
Please, email Xunlong and ask your questions. See if you get any response back, or how helpful it is.
This forum has a search feature. A contributing factor to this "abusive language" as you put it, is that 20 people ask the same questions over and over again instead of searching the forum for the last time this question was asked, looking at the answer, and then accepting that the situation isn't as they had hoped.