The communication part is abnormal

When I use MNK(64,9216,4608) and run sample/matul-reduce.cu, I found a separate test and found the following problems. After exchanging the value of MN, I found that the final result after communication is wrong, and the communication time gap is large. Therefore, I suspect the communication kernel Is there a bug in it? Can you help me to look it up and explain it? The result is as follows
The result should be that running MNK(9216,64, 4608)  succeeded, but running MNK(64,9216, 4608) failed
NCCL INFO Launch mode Parallel
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
checking results at iter 0
rankk -1 Mismatch at 0 : ref '36864.000000', computed '4608.000000'
iter 20
iter 40
iter 60
iter 80
iter 100
AllReduce+cuBLASMatMul: channel 12 buffer_size 9437184 MUL [64, 4608] X [4608, 9216]: TotalTime 19.334793 ms, AllReduceTime 9.166956 ms, cuBLAS Time 8.098815 ms

[0] NCCL INFO Launch mode Parallel
checking results at iter 0
iter 20
iter 40
iter 60
iter 80
iter 100
AllReduce+cuBLASMatMul: channel 12 buffer_size 9437184 MUL [9216, 4608] X [4608, 64]: TotalTime 28.081179 ms, AllReduceTime 17.275572 ms, cuBLAS Time 8.818693 ms

Hi,
I am not surprised by it. AllReduce was modified heavily to do 2-D communication tiles and was mainly tested on GPT-2 and GPT-3 sizes. Supporting these sizes will require significant work. We are already working on 2-D tile communication in a separate project and I will share it once it is done.

Okay, thank you very much. I'm looking forward to an optimized version of NCCL that can support different model sizes.
I am very interested in your project and would like to participate. Can I also ask you a few questions?
first.

Supporting these sizes will require significant work.

May I ask what work you have done with NCCL and have you modified the list of file names in the standard NCCL？

If I want to test the effect on non GPt2/3, which files do I need to modify in https://github.com/parasailteam/coconet-experiments ?

In your latest paper, you used cutlass in the calculation section, but the implementation of cutpass looks very complex. Can you please provide the nccl modification implementation corresponding to using cubals+ALLReduce (non cutpass in Gemm calculation section) in your first version?

Can you make a separate issue with these questions?


Solve warnings in latest Github actions

Solve the warnings (nodejs version) in the reports of the latest Github actions

Resolved by #5


Symbols for inlined functions

We need special handling for symbol to inlined functions.

The problem is that we if we ever see a function symbol we just assume that we assume its the start of a function and do no special handling of it.  We should detect when a symbol is pointing into a basic block of another function and emit a tail call.

This is causing some issues with mcsema, mainly with tail calls to an external function. The thunk will just get inlined and never gets lifted as a separate function, since there's no symbol/address being picked up

Fortunately I think this will be fixed by one of my current tasks, which is adding symbol binding types, including local, global and weak.

We haven't seen this issue in some time and we don't have a binary on hand to reproduce it. If anyone comes up with a binary that exhibits this behavior, please re-open this issue and let us know. It's hard for us to fix this without having a test case we can use to reproduce the issue.


chore: update README

Codecov Report

Merging #874 into master will decrease coverage by 26.38%.
The diff coverage is n/a.


Ambassador application - Dan Kelosky

Email
<EMAIL_ADDRESS>Bio
Dan Kelosky is a Software Architect helping to build Devops and Zowe solutions within Broadcom.  Dan started mainframe development in 2009 coding IBM assembler and Metal C.  He has since written code for web UIs (HTML, CSS, & Typescript), for distributed systems (C++, Java, & Node.js), and for desktop applications (Node.js, Rust).
Projects within OMP you would want to be an ambassador for
Zowe
List any other topics you would be able to speak about
Mainframe software development, Node.js, TypeScript, HLASM, Metal C, VS Code Extension Development
Why do you want to be an ambassador?
I try to be one already through medium posts, LinkedIn, SHARE participation, and coding within Zowe.
Attach a headshot

Hey @dkelosky - since you are already an Ambassador - no need to reapply.


RY835AI GPS Connections

Looking for definitive pinouts and settings based on the latest .5 beta code.  These are the latest pinouts most are using but the RY835AI shows multiple trigger grounds... should we be using or tying the grounds to ensure proper operation? There are many people posting of intermittent signal, long lock times, and other abnormalities.. are we hooking this up right!
Also, does the stratux code set the units internal settings for gps refresh rates>? The unit comes factory default at 1HZ but can be modified up to 18Hz.  How about baud rates and ports?  Some hook up via usb then connect to gpoi and that solves some issues.. so I am thinking this is a gps board settings issue.
Does the hardware store almanac and ephemeris   data for warm/hot and assisted startup or do we need to store that via software.  I assume some settings (port data/refresh rates/etc) are being retained in the unit via non vol memory while catalog and gps ephemeris are being held by the rechargeable onboard battery.  Anyone test how long that battery lasts?
as for the gyros and other sensors.. see my other post.. I believe there are sever good open source code projects that will give us full AHRS and imu/inu functionality.
Power:
VDD -> PIN 02
GND -> PIN 06
AHARS Data:
SDA1 -> PIN 03
SCL1 -> PIN 05
GPS Data:
TXD -> PIN 10
RXD -> PIN 08
spec sheet here
http://www.reyax.com/Module/GPS/RY835AI/RY835AI.pdf

I thought I was the only one having strange GPS results.  It seems to work for a while after I connect the GPS to my laptop and perform a cold reboot.  Then re-connect it to Stratux via GPIO.  I am open to help with testing and coding.

Some discussion a while back regarding long lock times centered around the small capacity of the onboard lithium cell. It's something like 50mAh, which is maybe around a week of standby tops. Most (not all) of us are probably flying less than weekly, so it has plenty of time to drain and then think it's off the coast of Equatorial Guinea.
I don't know that anyone else has fiddled with the wiring, but at the time I wondered about replacing the tiny cell with a bigger one like a lithium CR3032, which is 500mAh.

starting a new thread on realistic hardware goals

The issue I have with GPS is not related to it being off too long.  I can have a WAAS lock on it, power cycle the Stratux.  Then end up with either no GPS lock after letting it sit powered on over night.  Repeated power off's won't fix it.  I have to perform a GPS cold restart to have it re-establish a lock.  I have used the ubox windows tool to monitor what is going happening and noticed that it will be quick to pickup a couple of satellites.  Not enough to even get to 3D tracking.  And they they will all drop for a second and it has to find them again.

The NEO-M8M data sheet states for both GPS/GLONASS and GPS/BeiDou configs
max update rate is 5Hz and a GPS only config is 10Hz. Could someone that's
having lock problems try dropping the update rate down to 5 Hz and see if
there's any change in behavior.
You'd need to use u-center to get the 5Hz UBX-CFG-RATE-Measurement period
values and make changes in main/ry835ai.go
// Set 10Hz update.
p.Write(makeUBXCFG(0x06, 0x08, 6, []byte{0x64, 0x00, 0x00, 0x01, 0x00,
0x01}))
from the NEO-M8 data sheet
TCX) or Crystal               GNSS              GPS & GLONASS     GPS &
BeiDou           GPS
Max nav update rate     NEO-M8N
5Hz                            5Hz                   10Hz
NEO-M8N/Q
10Hz                           10Hz                  18Hz
On Mon, Dec 14, 2015 at 7:01 AM, brockhoff<EMAIL_ADDRESS>wrote:

The issue I have with GPS is not related to it being off too long. I can
have a WAAS lock on it, power cycle the Stratux. Then end up with either no
GPS lock after letting it sit powered on over night. Repeated power off's
won't fix it. I have to perform a GPS cold restart to have it re-establish
a lock. I have used the ubox windows tool to monitor what is going
happening and noticed that it will be quick to pickup a couple of
satellites. Not enough to even get to 3D tracking. And they they will all
drop for a second and it has to find them again.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-164430656.

factory default I believe is 1hz and I doubt anyone is changing that config.. could be wrong.
looking at the data sheet and seeing 3 ground signals and most are only wiring one ground to me sounds like it could be an issue.. signal grounds are key to keep noise out of the signal waveforms going to the pi.. garbage in garbage out?

On Mon, Dec 14, 2015 at 9:17 AM, duecedriver<EMAIL_ADDRESS>wrote:

factory default I believe is 1hz and I doubt anyone is changing that
config.. could be wrong.

yes, you're wrong; did you not read the part about the value being set in
main/ry835ai.go
// Set 10Hz update
p.Write(makeUBXCFG(0x06, 0x08, 6, []byte{0x64, 0x00, 0x00, 0x01, 0x00,
0x01}))

nope didnt catch that.. honestly having a hard time finding and following documentation on the project..
central documentation would really help people figure out whats going on without having to read all the source code for notes or at least a running doc for each process...
keep in mind that even with a good backup battery ... saved almanac and ephemeris data is only good for a short period of time... ephemeris data is considered good for 30 mins.. otherwise its a cold start
what is probably happening on cold starts is the gps start position might be defaulting back to a lat long of 0 ,0  in that case with an inaccurate start location and no almanac it takes the unit forever to orient to the constellation and get its initial fix and begin the 13 minute almanac download.. then update ephemeris
with a hand held or other consumer gps.. if it senses its a cold start.. it usually asks you to click on a present position on a map to give it a head start.
in the USAF, we were required to take our survival radio/handhelds out periodically from our survival gear and let it update almanac data and get a starting fix.. and they had huge batteries..
for the U-2, it was usually connected to a external gps antenna and let it align and warm up for over an hour during preflight to have a highly precise location and ephemeris updates.. but then my INU was so sensitive it had to calibrate for more than an hour to sense the earths rotation too

if allowing the user to specify a default starting point for the GPS will significantly accelerate lock, then that would not be a big thing to add.
Doe the hardware support setting the lat/lon starting position?
What do others think?

Have you checked the cgsic site for possible gps sat outage?
On 12/14/2015 07:01 AM, brockhoff wrote:

The issue I have with GPS is not related to it being off too long. I
can have a WAAS lock on it, power cycle the Stratux. Then end up with
either no GPS lock after letting it sit powered on over night.
Repeated power off's won't fix it. I have to perform a GPS cold
restart to have it re-establish a lock. I have used the ubox windows
tool to monitor what is going happening and noticed that it will be
quick to pickup a couple of satellites. Not enough to even get to 3D
tracking. And they they will all drop for a second and it has to find
them again.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-164430656.

This kind of stuff isn't what I do, but I'm just trying to help so apologies if this is redundant or useless. That said...
Looking over the M8 Documentation Section 9, it lists the ways to speed up starts but most require the host to fetch data from the Internet. Their "AssistNow Autonomous" (Section 9.6) seems the most useful to us as it works completely offline with data it already has:

Based on a broadcast ephemeris downloaded from the satellite (or obtained by AssistNow
Online), the receiver can autonomously (i.e. without any host interaction or online connection) generate an accurate satellite orbit representation that is usable for navigation much longer than the underlying broadcast ephemeris was intended for. This makes downloading new ephemeris or aiding data for the first fix unnecessary for subsequent start-ups of the receiver.

It sounds like it adds a few days of life to the last ephemeris. Not great, but better than nothing. It's also disabled by default. Does this sound like something worth turning on?

My guess is it is not a problem with the GPS taking long on a cold startup.  If I force it to do a cold startup then it will get a 3D lock in about 15-20 mins.  After it gets a 3D lock I will power it off/on.  So I would expect the battery would be able to hold the satellite almanac and allow it to get 3D lock quickly.  this does happen most of the time.  But some times it does not.  And when It does not then it will never get a 3D lock until I force a cold startup.
I was also thinking about all the ground connections on the RY835AI.  I an email to their support and they never answered my question.
This issue does not appear to happen when I connect the RY835AI to the Stratux USB.

Yes, AssistNow will help - if anyone wants to add in it would be great. @jamez70 ??

If you think that would help we could make it work. uBlox doesn't give access to that freely though if I remember correctly.
I had mentioned previously that at my day job we had to switch uBlox 8 modules because one of them would either take a very long time to lock or not lock at all.

Just forwarded you my API key for the u-blox AssistNow data files

Cool thanks. I'll look at it tonight
On Mon, Dec 14, 2015 at 7:27 PM, cyoung<EMAIL_ADDRESS>wrote:

Just forwarded you my API key for the u-blox AssistNow data files
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-164612335.

Ok, I wrote something and it might work. I did a pull request so you could take a look. If you could, test it. I need to check acknowledgements though before I would call it done.

Ok I wrote some code, but need to test it more
On Mon, Dec 14, 2015 at 7:28 PM, Jim Jacobsen<EMAIL_ADDRESS>wrote:

Cool thanks. I'll look at it tonight
On Mon, Dec 14, 2015 at 7:27 PM, cyoung<EMAIL_ADDRESS>wrote:

Just forwarded you my API key for the u-blox AssistNow data files
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-164612335.

We have been using the same pin configuration since August,  I have seen a picture on reddit recently that had the ground jumped to another pin.  Since the beginning we have been using the pin configuration that @duecedriver has posted with a single ground on pin 6.  This configuration has seemed to work for a lot of folks.  Not sure where the extra ground is coming from, maybe I missed something?  IMO I think that some folks are just getting bum GPS units or their soldering skills are not up to the task, also that unit is pretty small, there is a chance that in the process of soldering the headers  you could actually damage or overheat it.

Well the more I look at the schematic the more inclined I am to thinking we have not taken the time to wire this chip correctly.
From what I remember of digital and analog ic curcuit design..(25 years ago), multiple grounds to ensure voltage floors and waveform squareness are not put on the boards for their good looks.
additionally, there is pin 8 which is an input pin FSYNC for the MPU, it states wire to ground if not used.
That makes 4 grounds and we are wiring 1.  The PDF spec sheet is poor to explain the circuit logic but it is becoming more clear that we probably have lots of noise going on here, possibly voltage irregularities since there are several 3.3v 2ohm pull-ups in use on these circuits...
there is a blurb in the u-block data sheet that warns that all grounds and voltages be carefully managed to avoid over stressing components as they can be damaged by voltage spikes and voltage float.
Again we are hooking into the pi +5 line that is notoriously unreliable especially when 2 radios are being used without the powered hub, we give it a single ground (which may only gound the 5v power source) not providing a ground for the 3.3v signal sources may further allow voltage float and not provide square waveforms.
So convinced that this is the problem  I found a blurb in the u-blox hardware integration manual that states
Electromagnetic interference on I/O lines
Any I/O signal line with a length greater than approximately 3 mm can act as an antenna and may pick up arbitrary RF signals transferring them as noise into the GNSS receiver. This specifically applies to unshielded lines, in which the corresponding GND layer is remote or missing entirely, and lines close to the edges of the printed circuit board.
https://www.u-blox.com/sites/default/files/NEO-M8_HardwareIntegrationManual_(UBX-13003557).pdf
we are also clearly not utilizing all data i/o pinouts and I cant speak to their individual requirements but this may also explain why folks have less issues over usb.
The USB spec required the i/o and power to be internally regulated .. when utilizing the header pins, we are now responsible for ensure all power and grounds are good, that all data channels are connected to their various sources and targets, etc..
I am fairly convinced that we need to have someone that is a lot smarter than me reference the hardware integration guides of these chips to figure out how to wire it for full performance.
also the u-bloc guides talk a lot about assisted startup
thoughs

why dont we put the GPS on the i2c bus with the ahrs?
again. I am trying to get with reyax to see how they are using the 6050.. are they outputing raw axis data or using the 6050 onboard software processing that is supposed to fuse the data.  a 6050 on a separate breakout board gives you the option.. I dont know what there are doing here.  We are also not using the fsync or interrupts while most of the other people using a 6050 are using these..
lacking the additional grounds that the chip provides may be allowing noise into the ahrs data?

It is difficult to use interrupts in standard Linux, which is what's on
the Pi.  Essentially, you have to change the kernel.  It is done but it
ain't easy.
On 12/17/2015 08:39 AM, duecedriver wrote:

why dont we put the GPS on the i2c bus with the ahrs?
again. I am trying to get with reyax to see how they are using the
6050.. are they outputing raw axis data or using the 6050 onboard
software processing that is supposed to fuse the data. a 6050 on a
separate breakout board gives you the option.. I dont know what there
are doing here. We are also not using the fsync or interrupts while
most of the other people using a 6050 are using these..
lacking the additional grounds that the chip provides may be allowing
noise into the ahrs data?
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165468626.

If you want to get DMP (Digital Motion Processor) output from the 6050, play with this:
https://github.com/cyoung/linux-mpu9150
It's not using hardware interrupts, there is a sample queue on the 6050 which is small - and depending on the sample rate, usually can be read in without missing or overflowing. Not the best setup but you can at least use it to evaluate the performance roughly.

@duecedriver -
We don't use FSYNC because this isn't a mobile phone, and we're not trying syncrhonize accelerometer signals with optically stabilized image capture.
Tying the grounds together is a red herring. All of the grounds on the RY835AI board are tied, with < 0.2 Ohm resistance, because the whole bottom layer of the board, save for the signal and power traces, is one big ground plane. Even the gold-plated mount pads on the corners of the board are part of the ground.
In my experience, an electrically "clean" M8N receiver will position lock within three minutes on a cold startup -- that's indoors, with no real-time clock, no almanac, no previous position.
That said, EM interference can be and is a problem. I've seen UART noise show up as gibberish on the serial console (i.e. cat /dev/ttyAMA0 showed random ascii characters interspersed in the NMEA messages), and suspected crosstalk between the TX/RX UART lines (possibly caused my poor repair workmanship by yours truly). That confused the hell out of the receiver and apparently prevented GPS lock. Unplugging the Pi TX / ublox RX line instantly caused the "lock" indicator to flash and normal messages to stream.

what I want to know is if its even available in the RY chip.. they have the 6050 on board but it has 2 modes.. which are they using..  the manufactured cant even tell me..
invensence.. the company that makes it finally opened up the code to use it for developers.. you can get a free account to access the standards and some example code routines.. but did reyax make it available or not?

On Dec 17, 2015, at 10:01 AM, cyoung<EMAIL_ADDRESS>wrote:
If you want to get DMP (Digital Motion Processor) output from the 6050, play with this:
https://github.com/cyoung/linux-mpu9150 https://github.com/cyoung/linux-mpu9150
It's not using hardware interrupts, there is a sample queue on the 6050 which is small - and depending on the sample rate, usually can be read in without missing or overflowing. Not the best setup but you can at least use it to evaluate the performance roughly.
—
Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/142#issuecomment-165476668.

What modes are you referring to?

Things get really complex with the "DMP".
The sensor has a "Digital Motion Processor" (DMP), also called a "Digital Motion Processing Unit". This DMP can be programmed with firmware and is able to do complex calculations with the sensor values.
For this DMP, InvenSense has a discouragement policy, by not supplying enough information how to program the DMP. However, some have used reverse engineering to capture firmware.
The DMP ("Digital Motion Processor") can do fast calculations directy on the chip. This reduces the load for the microcontroller (like the Arduino). The DMP is even able to do calculations with the sensor values of another chip, for example a magnetometer connected to the second (sub)-I2C-bus.

the DMP package is supposed to do all the vector calcs etc.. it is on an i2c bus with the compass and pressure sensor according to the reyax but they cant tell me if the installed it to use the DMP or not..  invensence has a developer section I think I sent you a link where you can now download the code and the developers tools and specs for the 6050 but if it was not installed by reyas to get at it.. it may or may not work...

there is probably a world of difference on how the bus and signal noises are on the ground in the kitchen vs in the aircraft sitting on top of the avionics stack with a 60 yo generator providing enough noise to power detroit ...and a transponder and other radios leaking RF

@AvSquirrel
ok fair enough on fsync.. however according to the manufacturers integration doc.. if it is not used it is supposed to be grounded.
additionally, if a singe ground would work I dont see why they provide 3..
again... I have read the integrators docs for the 6050 and the GPS chip on this board and they all harp on the ground criticality as well as RF shielding and ESD damage potential ...

also.. i have seen several projects that are using the 6050 on arduino and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c because of noise.. in an aircraft that goes up by a factor of 10...

@duecedriver
Remember that Arduino is a microcontroller, which lives and dies by interrupts. Raspberry Pi is a full-fledged 32-bit computer with a gigabyte of RAM... it's a completely different world.
When you get down to nuts and bolts, the Reyax board is nothing more than a breakout board that puts four useful little modules onto a single piece of epoxy glass for the sake of convenience -- you have a common filtered power source to supply for all modules, and three modules (gyro/accel, pressure sensor, magnetometer) are electrically combined onto the same I2C bus to create an ersatz 10-DOF sensor.
I'd guess that the purpose for three grounds (really four, if you count the USB connector) is to provide a dedicated solder point for each set of signal leads. Notice that one is adjacent to the GPS UART pins; one is near the gyro/accel/pressure/magnetometer I2C, and the third is near the GPS I2C.

exactly ..dedicated grounds for each signal path… roger that…
yes.. I know the RY chip is packaged bunch of chips.. hence not finding the info I needed from rayax I looked up the individual microchips… so again it comes down to the question.. is the 6050 processor set up to use on board IMU code or not.. if it is supposed to do sensor fusion we are either
1 not using the proper commands to get the data or activate the controller
2 getting too much noise on the i2c bus to the pi thereby not getting good signals since in the video of it running in an aircraft .. it does not seem to respond at all to aircraft motion…
lets not forget the instructions say to ground rsync if not in use so that is another ground..
i read a whole bunch on the proper setup of i2c busses and is seems a bit more involved than just connecting 2 wires for clock and data…

On Dec 17, 2015, at 2:44 PM, AvSquirrel<EMAIL_ADDRESS>wrote:
@duecedriver https://github.com/duecedriver
Remember that Arduino is a microcontroller, which lives and dies by interrupts. Raspberry Pi is a full-fledged 32-bit computer with a gigabyte of RAM... it's a completely different world.
When you get down to nuts and bolts, the Reyax board is nothing more than a breakout board that puts four useful little modules onto a single piece of epoxy glass for the sake of convenience -- you have a common filtered power source to supply for all modules, and three modules (gyro/accel, pressure sensor, magnetometer) are electrically combined onto the same I2C bus to create an ersatz 10-DOF sensor.
I'd guess that the purpose for three grounds (really four, if you count the USB connector) is to provide a dedicated solder point for each set of signal leads. Notice that one is adjacent to the GPS UART pins; one is near the gyro/accel/pressure/magnetometer I2C, and the third is near the GPS I2C.
—
Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/142#issuecomment-165561045.

The Bosch BNO055 has it, too, and is active and available as soon as the
chip is powered up.  It's also easy to use.  :)
On 12/17/2015 01:14 PM, duecedriver wrote:

Things get really complex with the "DMP".
The sensor has a "Digital Motion Processor" (DMP), also called a
"Digital Motion Processing Unit". This DMP can be programmed with
firmware and is able to do complex calculations with the sensor values.
For this DMP, InvenSense has a discouragement policy, by not supplying
enough information how to program the DMP. However, some have used
reverse engineering to capture firmware.
The DMP ("Digital Motion Processor") can do fast calculations directy
on the chip. This reduces the load for the microcontroller (like the
Arduino). The DMP is even able to do calculations with the sensor
values of another chip, for example a magnetometer connected to the
second (sub)-I2C-bus.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165552199.

I have not look at the electrical specs in a long time.  Sometimes there
is a sinal ground as well as power ground.  Definitely so with
thermocouples.
On 12/17/2015 01:22 PM, duecedriver wrote:

@AvSquirrel https://github.com/AvSquirrel
ok fair enough on fsync.. however according to the manufacturers
integration doc.. if it is not used it is supposed to be grounded.
additionally, if a singe ground would work I dont see why they provide
3..
again... I have read the integrators docs for the 6050 and the GPS
chip on this board and they all harp on the ground criticality as well
as RF shielding and ESD damage potential ...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165554660.

The Arduino does not run Linux but the Pi2 does.  Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165555930.

I don't understand. I use interrupts in Linux all the time.
Josef
Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy<EMAIL_ADDRESS>wrote:
The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165555930.

—
Reply to this email directly or view it on GitHub.

Unfortunately, Linux Torvalds did not include interrupt handling in the
kernel of Linux.

Huh?  What's listed in /proc/interrupts?
On Thu, Dec 17, 2015, 15:49 skypuppy<EMAIL_ADDRESS>wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165555930.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165590339.

Those are in kernel modules
On Dec 17, 2015 4:11 PM, "Kris Knigga"<EMAIL_ADDRESS>wrote:

Unfortunately, Linux Torvalds did not include interrupt handling in the
kernel of Linux.

Huh? What's listed in /proc/interrupts?
On Thu, Dec 17, 2015, 15:49 skypuppy<EMAIL_ADDRESS>wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165555930.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165590339.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165595038.

Those are in kernel modules

Some of them, sure, but not all of them.
But, I fail to see how that's a problem.
On Dec 17, 2015 16:25, "jamez70"<EMAIL_ADDRESS>wrote:

Those are in kernel modules
On Dec 17, 2015 4:11 PM, "Kris Knigga"<EMAIL_ADDRESS>wrote:

Unfortunately, Linux Torvalds did not include interrupt handling in the
kernel of Linux.

Huh? What's listed in /proc/interrupts?
On Thu, Dec 17, 2015, 15:49 skypuppy<EMAIL_ADDRESS>wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on
arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub
<https://github.com/cyoung/stratux/issues/142#issuecomment-165555930
.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165590339.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165595038.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165598352.

Hardware interrupts?  You must have some of the rare real-time kernels.
On 12/17/2015 04:07 PM, Josef Zeevi wrote:

I don't understand. I use interrupts in Linux all the time.
Josef
Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy<EMAIL_ADDRESS>wrote:
The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165555930.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165594190.

You can do user space interrupts but don't hold your breath
On Thu, Dec 17, 2015 at 10:00 PM, skypuppy<EMAIL_ADDRESS>wrote:

Hardware interrupts? You must have some of the rare real-time kernels.
On 12/17/2015 04:07 PM, Josef Zeevi wrote:

I don't understand. I use interrupts in Linux all the time.
Josef
Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy<EMAIL_ADDRESS>wrote:
The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on
arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub
<https://github.com/cyoung/stratux/issues/142#issuecomment-165555930
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165594190.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165665357.

And they are a pain in the patoot to code for, while keeping everything
else on the stack rolling and in sync, not losing polled samples, etc.
On 12/17/2015 04:25 PM, jamez70 wrote:

Those are in kernel modules
On Dec 17, 2015 4:11 PM, "Kris Knigga"<EMAIL_ADDRESS>wrote:

Unfortunately, Linux Torvalds did not include interrupt handling
in the
kernel of Linux.

Huh? What's listed in /proc/interrupts?
On Thu, Dec 17, 2015, 15:49 skypuppy<EMAIL_ADDRESS>wrote:

The Arduino does not run Linux but the Pi2 does. Unfortunately, Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on
arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of 10...
—
Reply to this email directly or view it on GitHub

https://github.com/cyoung/stratux/issues/142#issuecomment-165555930.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165590339.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165595038.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165598352.

Yeah, hardware interrupts that are not handled in real-time are not true
interrupts.  They're more of a 'tickle.'
On 12/17/2015 10:03 PM, jamez70 wrote:

You can do user space interrupts but don't hold your breath
On Thu, Dec 17, 2015 at 10:00 PM, skypuppy<EMAIL_ADDRESS>wrote:

Hardware interrupts? You must have some of the rare real-time kernels.
On 12/17/2015 04:07 PM, Josef Zeevi wrote:

I don't understand. I use interrupts in Linux all the time.
Josef
Sent from a phone with a tiny screen

On Dec 17, 2015, at 3:49 PM, skypuppy<EMAIL_ADDRESS>wrote:
The Arduino does not run Linux but the Pi2 does. Unfortunately,
Linux
Torvalds did not include interrupt handling in the kernel of Linux.
Yes, it can be done but it is a real PIA.
On 12/17/2015 01:27 PM, duecedriver wrote:

also.. i have seen several projects that are using the 6050 on
arduino
and they are all using the interrupt pin for IMU..
and I have asked but are we activating the pi's pull-ups on
the i2c
channel.. the chip has built in 2.2k pull ups
again... lots of folks complain about edge detection issues on i2c
because of noise.. in an aircraft that goes up by a factor of
10...
—
Reply to this email directly or view it on GitHub

<https://github.com/cyoung/stratux/issues/142#issuecomment-165555930

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165594190.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165665357.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165665572.

I got a kernel level ISR working for a data acquisition project. I found that user level ISRs (with wiringPi for example) have a latency of 25us and up. I needed a little better so I came up with this kernel level driver for interrupting on the rising edge of a gpio and writing data to a file, latency is reduced to 2.5us to 7us. There were lots of challenges, I put a description of the project here https://sites.google.com/site/hamlinhomeprojects/projects/raspberry-pi-isr
the source code is attached.
Enjoy,

some folks are citing that interrupts are required to use on board processing on the 6050... otherwise we are just reading raw angles?  In order to use the on board calcs and the FIFO we need to wire the interupts...
I tried benchmarking the frequency of the DMP example, and here's what I noticed:
The MPU interrupts the code at 200Hz
However, the reading of the data is limited to 160Hz
The FIFO overflows, which is the reason for the drop in frequency
https://github.com/jrowberg/i2cdevlib/issues/135
again how this translates to the rayax board is anyones guess.. they have yet to return my email.

The tricky part can be to build the kernel module against the kernel, but I
don't expect that to be a problem If the BMP180 continues to lock up the
bus a kernel module solution may be the only way to recover from that.
On Fri, Dec 18, 2015 at 10:15 AM, duecedriver<EMAIL_ADDRESS>wrote:

some folks are citing that interrupts are required to use on board
processing on the 6050... otherwise we are just reading raw angles? In
order to use the on board calcs and the FIFO we need to wire the
interupts...
I tried benchmarking the frequency of the DMP example, and here's what I
noticed:
The MPU interrupts the code at 200Hz
However, the reading of the data is limited to 160Hz
The FIFO overflows, which is the reason for the drop in frequency
jrowberg/i2cdevlib#135 https://github.com/jrowberg/i2cdevlib/issues/135
again how this translates to the rayax board is anyones guess.. they have
yet to return my email.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-165820378.

Looks like REYAX has placed some updated information concerning the NEO-M8N
it can be found here https://www.u-blox.com/en/product-resources/2688
On the wiring the  data sheet instructs us to attach a ground wire on FSYNC that seemed to help me with mine to sync.

Been saying that for weeks. Also probably need to wire the rest of the grounds too since it's a voltage drain design and stray current and noise has to go across the board to a single drain the way most are hooking up. See my comments over on Reddit concerning signal noise and shielding.

About those grounds.  It is very difficult to get enough heat into the board to make a reliable solder flow connection on the grounds. The plated through ground connection holes are not buffered from the board and you are required to heat up a lot of copper to get a good flow.  I am cranking my solder pencil up and still not getting a great feeling about the heat penetration on the ground connection

As for shielding.  I am using some non conductive tap to cover the back of the REYAX board and then covering that with copper foil tape.  The finishing step is to bond the foil with a wire connecting it to ground.  This seems to work pretty good on the GPS antenna on my drone. But a drone has a lot more emf than the RPi.

I'm confused.....  1-prop-head states that REYAX has updated information concerning the NEO-M8N but gives a link to the u-box web site.  Also, based on the RY835AI documentation and the NEO-M8N documentation it looks like the FSYNC pin has nothing to do with the NEO-M8N chip.  From what I can read it looks like the FSYNC pin is going to the InvenSense MPU-6050 chip.
I do agree that all the grounds should be connected.  What I have noticed is that if I run the RY835AI connected through the USB only it will receive 12 satellites most of the time.  But if I run the RY835AI through the GPIO connection it will receive 4-5 satellites some times and other times it will loose all satellites.

Use two irons we do that at work all of the time
On Dec 22, 2015 9:43 AM, "1-prop-head"<EMAIL_ADDRESS>wrote:

About those grounds. It is very difficult to get enough heat into the
board to make a reliable solder flow connection on the grounds. The plated
through ground connection holes are not buffered from the board and you are
required to heat up a lot of copper to get a good flow. I am cranking my
solder pencil up and still not getting a great feeling about the heat
penetration on the ground connection
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-166650872.

Sorry u-box is the source of the info I used.  I can only guess that the FSYNC in a unbound state may be causing the module to execute some extra unnecessary service routines. Thanks to all this is a great project

in an unbound state the voltage is allowed to float causing erroneous on/off states... clearly states in the integration docs to ground if not used...
in my opinion if this chip is going to be used... all grounds need to be wired with none of the wires being routed  under the board.. none.. not ground, power or signal. best solution would be to mount the RY chip to a GPIO breadboard HAT.  the board needs to have a metal shield around it and grounded to the 4 corners of the board... the antenna needs to be surrounded by a gps ground plane that could be incorporated into the shielding.
the schematic of the RY chip shows some power filtering on the 5+ input and I believe that if i2c communications are not solid. proper i2c bus voltage pull-ups need to be put in place on the lines.

@brockhoff
correct, the fsync is for the 6050 and its i2c internal... but its still a ground and signal source so it should be wired correctly to prevent noise from entering the components.. any components on the chip

Dumb question, can you use USB just for GPS and GPIO for the AHRS ?   I seen posts where users are reporting less than 12 satellites when using only the pins.

You can

yep however I cant find on the spec sheet what the max update rates are over one vs there other.. and dont forget to harden the micro usb connector with some epoxy or something or it will break off in short order.
grounding of the board and shielding the board and giving the antenna a ground plane will improve even the usb connected device

On Dec 22, 2015, at 6:45 PM, cyoung<EMAIL_ADDRESS>wrote:
You can
—
Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/142#issuecomment-166763554.

I've seen numerous comments about usb working better for people than pins. Why would this be? It can't be grounding because the microusb header looks to connect to the same ground plane as everything else. It can't be the floating FSYNC pin, because it's it's floating when on usb (unless it's disabled via software?).

the usb standard would require the power and grounding and signal shielding etc.. the gps is still going out over the serial bus into the header pins witch require those wires to have good solder joints and the noise on the ground plane would be a bigger issue since the signal paths move about that ground plane...

Can someone point me in the right direction.  I am new to this.  I have assembled the receiver with the GPS.  I have made the connections in the post.  I can see the GNSS LED flashing, but I am not getting GPS output. Am I missing something?  Any help would be appreciated. If this is not the correct form, my apologies
stratuxlog.txt
.

Have you enabled the GPS in the Web UI?

Thanks for replying. Yes, everything is enabled. I am getting AHRS, traffic, and weather.  The AHRS symbol is skewed, but I see that is still being worked on.
Sent from my iPad

On Feb 2, 2016, at 10:14 PM, Axtel4<EMAIL_ADDRESS>wrote:
Have you enabled the GPS in the Web UI?
—
Reply to this email directly or view it on GitHub.

A couple of other things to try; Very the wiring between the RY and the R-Pi.  The most common error is swapping the TX and RX lines.
Also, if the GNSS led is blinking and you still doing see any GPS data on the Web UI, try cycling power on the Pi.  Sometimes it sherbet sync up with the GPS data if the GPS starts let.  This was addressed in 0.5r4 or 0.5r5 but it doesn't hurt to reset.
On February 3, 2016 3:05:19 AM CST, tdarrow<EMAIL_ADDRESS>wrote:

Thanks for replying. Yes, everything is enabled. I am getting AHRS,
traffic, and weather.  The AHRS symbol is skewed, but I see that is
still being worked on.
Sent from my iPad

On Feb 2, 2016, at 10:14 PM, Axtel4<EMAIL_ADDRESS>wrote:
Have you enabled the GPS in the Web UI?
—
Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHub:
https://github.com/cyoung/stratux/issues/142#issuecomment-179107612

Does it work with the USB cable?  That should tell you if it's your wiring or not.

Are there any advantages to direct wiring vs. using the RY835AI via USB?
From: braddward<EMAIL_ADDRESS>Sent: Wednesday, February 03, 2016 8:33 AM
To: cyoung/stratux
Cc: Josef Zeevi
Subject: Re: [stratux] RY835AI GPS Connections (#142)
Does it work with the USB cable? That should tell you if it's your wiring or not.
—
Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/142#issuecomment-179266853 .  https://github.com/notifications/beacon/APJ34TkeoVsguIfXCjOEFQClWejRLOdaks5pggcggaJpZM4G0UuQ.gif

I don't know if the AHRS works with USB.  Also, I've heard that the USB
connection on the RY835AI is very fragile and can't take any stress.
On Wed, Feb 3, 2016 at 8:44 AM Josef Zeevi<EMAIL_ADDRESS>wrote:

Are there any advantages to direct wiring vs. using the RY835AI via USB?
From: braddward<EMAIL_ADDRESS>Sent: Wednesday, February 03, 2016 8:33 AM
To: cyoung/stratux
Cc: Josef Zeevi
Subject: Re: [stratux] RY835AI GPS Connections (#142)
Does it work with the USB cable? That should tell you if it's your wiring
or not.
—
Reply to this email directly or view it on GitHub <
https://github.com/cyoung/stratux/issues/142#issuecomment-179266853> . <
https://github.com/notifications/beacon/APJ34TkeoVsguIfXCjOEFQClWejRLOdaks5pggcggaJpZM4G0UuQ.gif>
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-179271812.

Are there any advantages to direct wiring vs. using the RY835AI via USB?

It frees up a USB port for a different use.  Remember too, the USB connection can only connect the GPS portion, not the AHRS portion of the RY835AI.

Got it. For me, as a Foreflight user, that’s currently not a problem. I’ll look at direct wiring, though – seems like that offers more opportunity. J
Thanks!
From: JohnOCFII<EMAIL_ADDRESS>Sent: Wednesday, February 03, 2016 9:00 AM
To: cyoung/stratux
Cc: Josef Zeevi
Subject: Re: [stratux] RY835AI GPS Connections (#142)
Are there any advantages to direct wiring vs. using the RY835AI via USB?
It frees up a USB port for a different use. Remember too, the USB connection can only connect the GPS portion, not the AHRS portion of the RY835AI.
—
Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/142#issuecomment-179277743 .  https://github.com/notifications/beacon/APJ34dugemLikbM6XDFD3Vc85bZ2B6dwks5pgg1egaJpZM4G0UuQ.gif

I tried both way, and did not receive any data.  I'm not sure if I have a bad chip.  I tried to check it with the ublox center, but I could not get it to see the sub ports.
Sent from my iPad

On Feb 3, 2016, at 9:33 AM, braddward<EMAIL_ADDRESS>wrote:
Does it work with the USB cable? That should tell you if it's your wiring or not.
—
Reply to this email directly or view it on GitHub.

were you able to disconnect the hard-wired connections?  If you did and it
still doesn't work sounds like you may have a bad board then.
On Wed, Feb 3, 2016 at 10:09 AM tdarrow<EMAIL_ADDRESS>wrote:

I tried both way, and did not receive any data. I'm not sure if I have a
bad chip. I tried to check it with the ublox center, but I could not get it
to see the sub ports.
Sent from my iPad

On Feb 3, 2016, at 9:33 AM, braddward<EMAIL_ADDRESS>wrote:
Does it work with the USB cable? That should tell you if it's your
wiring or not.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-179316705.

On the RY, you should get a solid light at power up (I think it's green), and then once it receives a GPS lock it blinks (i think red) once a second.  I may have the colors reversed, but there's a green one and a red one; a solid one and a blinking one.  You can't get a blinking one without a solid one.  You only mentioned a blinking light.  Are you seeing both?

One last thing - you may want to leave it on for an extended period in a
place where you know it can pick up a signal (by a window or even outside
if you can).  Others have discussed that it can take significant time for
it to figure out where it is initially after it's trip from China.  Once
it's got that solution it's battery backed up.  I've also heard that the
battery backup on the chip doesn't last a long time either.
On Wed, Feb 3, 2016 at 10:40 AM Nokomis449<EMAIL_ADDRESS>wrote:

On the RY, you should get a solid light at power up (I think it's green),
and then once it receives a GPS lock it blinks (i think red) once a second.
I may have the colors reversed, but there's a green one and a red one; a
solid one and a blinking one. You can't get a blinking one without a solid
one. You only mentioned a blinking light. Are you seeing both?
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-179332715.

I checked the connections.  I had to switch the transmit and receive around.  As soon as I did that I has GPS signal.  I then shut the pi down so that I could reassemble the case.  Now I have the green power led, but no red flashing led.  When I look at the status on the web page I see the following
UAT towers    0
GPS solution  No Fix
GPS satellites 0 in solution; 3 seen; 10 tracked
I am currently letting it sit next to a window to see if there is any change
Once again, thanks for your help.
Sent from my iPad

On Feb 3, 2016, at 11:58 AM, braddward<EMAIL_ADDRESS>wrote:
One last thing - you may want to leave it on for an extended period in a
place where you know it can pick up a signal (by a window or even outside
if you can). Others have discussed that it can take significant time for
it to figure out where it is initially after it's trip from China. Once
it's got that solution it's battery backed up. I've also heard that the
battery backup on the chip doesn't last a long time either.
On Wed, Feb 3, 2016 at 10:40 AM Nokomis449<EMAIL_ADDRESS>wrote:

On the RY, you should get a solid light at power up (I think it's green),
and then once it receives a GPS lock it blinks (i think red) once a second.
I may have the colors reversed, but there's a green one and a red one; a
solid one and a blinking one. You can't get a blinking one without a solid
one. You only mentioned a blinking light. Are you seeing both?
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-179332715.

—
Reply to this email directly or view it on GitHub.

I have never gotten a signal from my RY835AI. Lights are on and blinking but not GPS, no AHRS. I have radio ADS-B hits but no positions.

Send it to me and I'll test it for ya.
On 02/05/2016 01:42 PM, scmadden wrote:

I have never gotten a signal from my RY835AI. Lights are on and
blinking but not GPS, no AHRS. I have radio ADS-B hits but no positions.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-180515006.

You could try cat /dev/ttyACM0 (is that it?) With gen_gdl90 stopped
On Feb 5, 2016 4:13 PM, "skypuppy"<EMAIL_ADDRESS>wrote:

Send it to me and I'll test it for ya.
On 02/05/2016 01:42 PM, scmadden wrote:

I have never gotten a signal from my RY835AI. Lights are on and
blinking but not GPS, no AHRS. I have radio ADS-B hits but no positions.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-180515006.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-180593367.

Or minicom or cutecom, or etc.  I'm thinking it is more of a hardware
problem, but local tests should be run first, of course.
On 02/05/2016 04:24 PM, jamez70 wrote:

You could try cat /dev/ttyACM0 (is that it?) With gen_gdl90 stopped
On Feb 5, 2016 4:13 PM, "skypuppy"<EMAIL_ADDRESS>wrote:

Send it to me and I'll test it for ya.
On 02/05/2016 01:42 PM, scmadden wrote:

I have never gotten a signal from my RY835AI. Lights are on and
blinking but not GPS, no AHRS. I have radio ADS-B hits but no
positions.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-180515006.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-180593367.

—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-180597560.

When I connect it to my computer I get a gps signal. Just not coming through the stratux.

@scmadden USB or GPIO? If GPIO, try USB and see if you get anything.

I have tried both. GPS connection just this afternoon broke.
Shawn C. Madden, Ph.D.
Major, USMC (retired)
On Feb 5, 2016 5:30 PM, "Daniel Whiting"<EMAIL_ADDRESS>wrote:

@scmadden https://github.com/scmadden USB or GPIO? If GPIO, try USB and
see if you get anything.
—
Reply to this email directly or view it on GitHub
https://github.com/cyoung/stratux/issues/142#issuecomment-180620548.

Try Reddit or Slack if further support needed.


validate link integrity

since some posts are rather old, I'd like to run tests to validate links pointing to third parties. I don't want to send users to a 404. Also some archived posts have links relative to the previous drupal install.
all of this can be accomplished with a grunt task that would be initialized when executing grunt test
relevant issue: #67

this can be accomplished with phantomjs and grunt

this seems like waaay too much work.


fix: hadcoded dcRedirectionPolicy parameter in server configmap

What was changed

removed harcoded dcRedirectionPolicy value from configmap template

Why?

user should be able to change dcRedirectionPolicy in values.yaml

Checklist

Closes

How was this tested:

Any docs updates needed?

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Victor Batuev seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Limit Filename in logs for privacy reasons.

The logger stores filenames including username if you rip in your home folder. (defaults)
Limit it to just the new directories.
This is what happens.
Track  1

     Filename /home/bober/album/Blind Melon - Blind Melon (Columbia House club edition)/01. Blind Melon - Soak the Sin.flac

     Pre-gap length  0:00:02.32

     Peak level 100.0 %
     Extraction speed 3.0 X
     Track quality 100.0 %
     Test CRC 89B34677
     Copy CRC 89B34677
     Accurately ripped (confidence 18)  [6C6D8E10]  (AR v1)
     Copy OK

This is what I expect.
Track  1

     Filename .../album/Blind Melon - Blind Melon (Columbia House club edition)/01. Blind Melon - Soak the Sin.flac

     Pre-gap length  0:00:02.32

     Peak level 100.0 %
     Extraction speed 3.0 X
     Track quality 100.0 %
     Test CRC 89B34677
     Copy CRC 89B34677
     Accurately ripped (confidence 18)  [6C6D8E10]  (AR v1)
     Copy OK

That's user controllable (not a setting specific to the logfile but a global morituri option).
Here's an excerpt from the man page:

Paths to track files referenced in .cue and .m3u  files  will  be  made  relative to the directory of the disc files.
All  files  will be created relative to the given output directory. Log files will log the path to tracks relative to this directory.

 -O OUTPUT_DIRECTORY, --output-directory=OUTPUT_DIRECTORY
                       output directory; will be included in file
                       paths in result files (defaults to absolute
                       path to current directory; set to empty if you
                       want paths to be relative instead)
 -W WORKING_DIRECTORY, --working-directory=WORKING_DIRECTORY
                       working directory; morituri will change to
                       this directory and files will be created
                       relative to it when not absolute

So the way it can be done is setting -O empty ('') and -W to the desired path (even cwd).
Hope this helps.

Cool thanks, is there a .conf option I can set? If not can it be added? I can recreate the ticker properly under https://github.com/JoeLametta/whipper if needed.

Sure, just edit the .moriturirc file located in the $HOME, appending the following:
[rip.cd.rip]
output_directory =
working_directory = path

Setting the working_directory is optional (include that line only if you prefer to use a static path): If not specified, whipper will save it's files to the cwd according to the track template.


Traceback - KeyError: 'Interface' (ERROR 500)

Describe The Problem
Flask comes up fine, but while trying to login recieve Error 500 on the browser and following Traceback
Expected Error / Traceback
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 2447, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1952, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1821, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python3.6/dist-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.6/dist-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "dashboard.py", line 501, in conf
    config_list = get_conf_list()
  File "dashboard.py", line 268, in get_conf_list
    temp = {"conf": i, "status": get_conf_status(i), "public_key": get_conf_pub_key(i)}
  File "dashboard.py", line 223, in get_conf_pub_key
    pri = conf.get("Interface", "PrivateKey")
  File "/usr/lib/python3.6/configparser.py", line 781, in get
    d = self._unify_values(section, vars)
  File "/usr/lib/python3.6/configparser.py", line 1141, in _unify_values
    raise NoSectionError(section)
configparser.NoSectionError: No section: 'Interface'
<IP_ADDRESS> - - [03/Jul/2021 13:47:11] "GET //configuration/wg0 HTTP/1.1" 500 -
<IP_ADDRESS> - - [03/Jul/2021 13:47:12] "GET /favicon.ico HTTP/1.1" 404 -
[2021-07-03 13:47:12,405] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
  File "/usr/lib/python3.6/configparser.py", line 1138, in _unify_values
    sectiondict = self._sections[section]
KeyError: 'Interface'

To Reproduce
Please provide how you run the dashboard
OS Information:

OS: Ubuntu 18.04.5 LTS
Python Version: Python 3.6.9

Sample of your .conf file
cat wg-dashboard.ini
[Account]
username = ######
password = ######

[Server]
wg_conf_path = /etc/wireguard
app_ip = <IP_ADDRESS>
app_port = 10086
auth_req = true
version = v2.1
dashboard_refresh_interval = 15000

Hi, could you please provide a sample of your wireguard config file? for example your wg0.conf

I think I found the cause of issue. I had an additional "valid" wireguard configuration named as wg0.conf.old in /etc/wireguard, once I removed the file, wgd daemon restarted, everything started working as expected.
I am still not sure why this would cause such an issue, even when the file name does not end with .conf. I would still consider this a bug, but please close if you think its not worth fixing.

I see, I will put this fix into the next version. Thank you for reporting this ;)