serial-port-json-server
serial-port-json-server copied to clipboard
johnlauer
Lost characters
I have this server running on Raspberry PI but it does not seem to be parsing the text properly.
I don't think I built it. Should I try that?
I guess I should have given more information, in chrome running chilipeppr the current location is not being displayed. Homing works but the display does not go to 0x0x0 on the top right hud.
Looking at chilipeppr the display looks like it was cut in half along word breaks.
It does not even look like sound JSON.
going to the web address: http://SPJSIP:8989/ does display correctly - think.
It looks like you had 7 Websockets connected? Or perhaps 7 quick attempts in a row? Something doesn't look right there. However, I also am concerned I don't see a version number next to TinyG which makes me ask what version of TinyG firmware are you using?
I am debugging the Android, iOS, and HMI (monodevelop) apps I made all at once - so 7 seems a bit high but is not impossible.
I am sure I am using the latest firmware. I recently went to upgrade it since I am having some motion problems where commands are queued but then never actually get sent to the controller.
Tempered,
Specifically what $fb are you running? We have and edge and master so the latest can be a bit confusing. I think this would help john out.
Riley
On Mon, Feb 8, 2016 at 3:52 PM, TemperedEnterprises < [email protected]> wrote:
I am debugging the Android, iOS, and HMI (monodevelop) apps I made all at once - so 7 seems a bit high but is not impossible.
I am sure I am using the latest firmware. I recently went to upgrade it since I am having some motion problems where commands are queued but then never actually get sent to the controller.
— Reply to this email directly or view it on GitHub https://github.com/johnlauer/serial-port-json-server/issues/39#issuecomment-181532087 .
I would run the stable branch without a good reason. So I am pretty sure I am running the latest stable.
$fb {"ej":""} [fb] firmware build 440.20 tinyg [mm] ok>
Funny enough - today everything seems to be working well. I didn't close the browser, didn't do anything I haven't done. But the parsing is good and homing works now.
That screenshot looks good On Feb 9, 2016 11:02 AM, "TemperedEnterprises" [email protected] wrote:
[image: spjs-issue-web3] https://cloud.githubusercontent.com/assets/6678979/12927329/4646b552-cf2d-11e5-9bad-5d71d54cf032.png
For comparison to above.
— Reply to this email directly or view it on GitHub https://github.com/johnlauer/serial-port-json-server/issues/39#issuecomment-182006800 .
It started doing it again so I restarted the server and there still seems to be issues. I am getting JSON wrapped in JSON that is incomplete. That screenshot above is after homing. All axis should be 0x0x0 but:
{"sr":{"posx":-547.000,"feed":3000.00,"vel":0.00}} 0{"sr":{"} "sr":{"posx":0.000,"posy":-7.286,"vel":1.29}} {} {"sr":{"posy":-6.876,"feed":100.00,"vel":100.00}} {"sr":{"posy":-6.468}} {"sr":{"posy":-6.060}} {"sr":{"posy":-5.651}}
it says -547
Maybe noise on your usb line? On Feb 9, 2016 2:33 PM, "TemperedEnterprises" [email protected] wrote:
[image: spjs-issue-web4] https://cloud.githubusercontent.com/assets/6678979/12932852/9c4f410e-cf4a-11e5-8225-6fccd2ebd16a.png
It started doing it again so I restarted the server and there still seems to be issues. I am getting JSON wrapped in JSON that is incomplete. That screenshot above is after homing. All axis should be 0x0x0 but:
{"sr":{"posx":-547.000,"feed":3000.00,"vel":0.00}} 0{"sr":{"} "sr":{"posx":0.000,"posy":-7.286,"vel":1.29}} {} {"sr":{"posy":-6.876,"feed":100.00,"vel":100.00}} {"sr":{"posy":-6.468}} {"sr":{"posy":-6.060}} {"sr":{"posy":-5.651}}
it says -547
— Reply to this email directly or view it on GitHub https://github.com/johnlauer/serial-port-json-server/issues/39#issuecomment-182109187 .
Noise does not care about digital or analog :) Try a different cable. I have seen crappy USB cables that were poorly shielded.
Riley
On Tue, Feb 9, 2016 at 7:09 PM, TemperedEnterprises < [email protected]> wrote:
USB is digital
— Reply to this email directly or view it on GitHub https://github.com/johnlauer/serial-port-json-server/issues/39#issuecomment-182141224 .
"Noise does not care about digital or analog :)"
Quite right - Electromagnetic interference does not care about how the signal is encoded. But you should in diagnostics.
http://www.usb.org/developers/docs/whitepapers/crcdes.pdf
If the cable was bad the result would be the same as if it were disconnected. There is no way that some data is just lost on the hardware transport layer.
"Try a different cable."
The hubris. It isn't your programming - it is a cable.
Should I piss on a spark plug as well?
"I have seen crappy USB cables that were poorly shielded."
As have I - and they would give an altogether different result. IE. the b device would be disconnected.
I am not sure I follow:
If the cable was bad the result would be the same as if it were disconnected.
I would not recommend pissing on a spark plug either.
Riley
On Wed, Feb 10, 2016 at 10:05 AM, TemperedEnterprises < [email protected]> wrote:
"Noise does not care about digital or analog :)"
Quite right - Electromagnetic interference does not care about how the signal is encoded. But you should in diagnostics.
http://www.usb.org/developers/docs/whitepapers/crcdes.pdf
If the cable was bad the result would be the same as if it were disconnected. There is no way that some data is just lost on the hardware transport layer.
"Try a different cable."
The hubris. It isn't your programming - it is a cable.
Should I piss on a spark plug as well?
"I have seen crappy USB cables that were poorly shielded."
As have I - and they would give an altogether different result. IE. the b device would be disconnected.
— Reply to this email directly or view it on GitHub https://github.com/johnlauer/serial-port-json-server/issues/39#issuecomment-182411928 .
John, I agree. I just checked out of this conversation :)
later.
On Wed, Feb 10, 2016 at 10:14 AM, Riley Porter [email protected] wrote:
I am not sure I follow:
If the cable was bad the result would be the same as if it were disconnected.
I would not recommend pissing on a spark plug either.
Riley
On Wed, Feb 10, 2016 at 10:05 AM, TemperedEnterprises < [email protected]> wrote:
"Noise does not care about digital or analog :)"
Quite right - Electromagnetic interference does not care about how the signal is encoded. But you should in diagnostics.
http://www.usb.org/developers/docs/whitepapers/crcdes.pdf
If the cable was bad the result would be the same as if it were disconnected. There is no way that some data is just lost on the hardware transport layer.
"Try a different cable."
The hubris. It isn't your programming - it is a cable.
Should I piss on a spark plug as well?
"I have seen crappy USB cables that were poorly shielded."
As have I - and they would give an altogether different result. IE. the b device would be disconnected.
— Reply to this email directly or view it on GitHub https://github.com/johnlauer/serial-port-json-server/issues/39#issuecomment-182411928 .
"That's a pretty rude response to people who are trying to help you."
So is telling someone to replace a part without hope of remedy. It's called the run-around.
I think I will go piss on a spark plug - since I have already had my time wasted with other nonsense.
Should I try a third cable?
Again, there is no way to get data transmission errors on a digital transport if the transmission layer is not register failures. That is not have computers and layering works.
"I am not sure I follow: If the cable was bad the result would be the same as if it were disconnected."
It's pretty simple. If the cable was bad - the com port would register and deregister in the system devices. It would not simply "lose characters"..
You can try it. Cut a cable and then make a crappy connection and then create a lot of noise on the line. The transmission rate will slow until 100% of the data cannot be sent and then the connection will be lost.