Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes for 2.5.9 #960

Merged
merged 18 commits into from
Oct 19, 2024
Merged

Changes for 2.5.9 #960

merged 18 commits into from
Oct 19, 2024

Conversation

garthvh
Copy link
Member

@garthvh garthvh commented Oct 10, 2024

What changed?

  • Update protos
  • Update Device hardware JSON

@@ -56,13 +56,13 @@ struct TraceRoute: Layout {

subview.place(at: point, anchor: .center, proposal: .unspecified)

DispatchQueue.main.async {
// DispatchQueue.main.async {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was running this branch earlier today and noticed that this change was causing the arrows between nodes to no longer angle correctly. They all pointed one direction until I uncommented these.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me, the app crashed when going from a multi-hop traceroute to a direct traceroute in the list. With this, this doesn't happen anymore, but indeed the arrows don't angle correctly anymore.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I reproduced that crash. Looks like it's probably referencing the subview data after it's getting torn down.
On the flip side, those assignments in this state trigger a "Modifying state during view update, this will cause undefined behavior” warning.

}
hopNodes.append(destinationHop)
/// Add the destination node to the end of the route towards string and the beginning of teh route back string
routeString += "\(traceRoute?.node?.user?.longName ?? "unknown".localized) \((traceRoute?.node?.num ?? 0).toHex()) \(traceRoute?.node?.snr ?? 0 > 0 ? traceRoute?.node?.snr ?? 0 : 0.0)dB)"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this checking whether the SNR is > 0? I'm seeing 0.0dB when I expect a negative SNR.
Also, if it's an unknown SNR (due to old firmware), this value will be -128.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would also be better to use the SNR values from the traceroute and not those corresponding to a node, because those will change when subsequent packets are received.

@garthvh garthvh merged commit 6ee3a4e into main Oct 19, 2024
2 checks passed
@garthvh garthvh deleted the 2.5.9 branch October 19, 2024 15:03
connectedHop.time = Date()
connectedHop.num = connectedPeripheral.num
connectedHop.name = connectedNode.user?.longName ?? "???"
connectedHop.snr = Float(routingMessage.snrBack.last ?? 0 / 4)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 0 / 4 intended here? Seems like this would resolve to 0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants