Hi, On Thu, Oct 20, 2022 at 10:17 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > Hello, > > miquel.raynal@xxxxxxxxxxx wrote on Wed, 19 Oct 2022 21:46:25 +0200: > > > Hi Alexander, > > > > aahringo@xxxxxxxxxx wrote on Sat, 15 Oct 2022 21:02:08 -0400: > > > > > Hi, > > > > > > On Sat, Oct 15, 2022 at 4:58 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > > > > > Hi Stefan, > > > > > > > > stefan@xxxxxxxxxxxxxxxxxx wrote on Wed, 12 Oct 2022 19:54:49 +0200: > > > > > > > > > Hello Miquel. > > > > > > > > > > On 06.09.22 10:21, Miquel Raynal wrote: > > > > > > Those instructions do not work anymore for several reaons: > > > > > > - Two out of the three files to download return a 404 error: > > > > > > * The binutils version does not exist, it was 2.21.1 or 2.21.1a > > > > > > instead of just 2.21. > > > > > > * The avr-libc is no longer hosted on the pointed website, I've > > > > > > found an alternate. > > > > > > - The binutils version mentioned is not able to compile the firmware on > > > > > > a recent distribution, the Internet advised to update its version and > > > > > > it worked. > > > > > > - Most of these compilations will throw warnings if you use a recent > > > > > > gcc. Sometimes -Werror is set and it fails the build. To avoid that, > > > > > > just use --disable-werror in the ./configure options. > > > > > > - I had issues building the gcc doc but those issues are trivial to > > > > > > fix inline. > > > > > > > > > > > > Update the instructions for building the toolchain and while at it, > > > > > > start the file by mentioning that this is maybe not useful anymore, and > > > > > > provide the packets to install. > > > > > > > > > > I can see that it was a frustrating process to get this working. :/ > > > > > Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log). > > > > > > > > Oh I'm not blaming anyone here ;) > > > > > > > > By the way I would like to make a another round of tests because during > > > > my demos I could observe a wrong LQI, and I don't remember if the LQI > > > > was valid before my changes or not. I haven't got the time yet to get > > > > back to it. Or maybe the devices were too close to each other? I don't > > > > know, I'll need to figure it out so we don't break a useful existing > > > > feature. > > > > > > What is a wrong LQI here? > > > > I just took the time to reproduce the demo, I get an LQI of 0xff with > > both firmware versions (before and after my changes). There are 2 > > meters between the devices, isn't it enough? > > I hard a hard time putting my two devices "far enough from each other" > on a radio POV, so I used a shielded bag, multiple USB cable > extensions, a microwave and my co-worker Köry to finally get a > reduced LQI. So nevermind, the hardware/firmware works as expected and > the firmware update we proposed recently did not break anything. note that one LQI value alone doesn't say anything about the link quality, also LQI value is a _very_ weak vendor specific thing how it's calculated. I heard successful reports also using aluminium foil around transceivers... - Alex
