Yeah, CTS and RTS is useful for the module since you may overflow the module buffer (instead of the module overflowing your UART buffer). With proper HW flow control, hopefully your device UART respects the signal and pauses the tx until it is clear again without you having to code the pause yourselves. It can happen when the GSM bandwidth is lower than the UART bandwidth.

The module suddenly talking should also be handled by your device UART gracefully. When your rx buffer is full for whatever reason (not reading it for a long time?), the module won’t be sending anymore data until you read your rx buffer. Theoretically, no data should be lost that way.

Since the posts are about SIM7600, and the example shows, it’s probably AT Command. So always newline delimited (either \r or \r\n)

I assume you mean RXD to TX0. As for sporadic packets like that, I’d honestly check for the signal integrity. Maybe somehow the data line is picking up noise high enough to cause disturbance. It could be caused by a lot of things, but the most likely culprit are the connector/cable. Any connection going into/out of pcb should be checked. Or check your timing. Make sure the baud and other config (start, data, stop, parity) are matched. Small drift in baudrate is usually tolerable. UART is designed for async communication after all, meaning that any device may send anytime so CTS and RTS isn’t usually needed provided that it is a hardware UART (not bit banging). You can check out Ben Eater video about it. In short, the TX is usually held high, the RX then can detect a falling edge which is a signal that a packet is starting. The UART hardware then processes the signal according to the config that you give it and is usually able to do a DMA transfer.

Edit: Ahh, after reading the code I suspect that your code processes the data faster than the module can send the full reply. The first loop that you are waiting for the first data to arrive, you immediately process everything in the buffer until it is empty, not knowing that maybe the module has not yet finished transmitting. CTS and RTS would not help since they are used to signal if both devices would like to (or probably could) send / receive data. Not signalling end of data transfer

Edit 2, the solution: Either parse the received packet until the expected end, or wait until timeout before returning.

Oh man, that manual is quite descriptive. I wish they could add a schematic or two there. But anyway, as others have suggested, be careful with CRT, but I guess you already know that. Next is from the circuit description, it seems like the display accepts some form or VGA signal without the color. You can see Ben Eater video to learn more about it, especially the line sync and vertical sync signal part

It matters for longer runs and higher speed. The twist provides noise cancellation effect

Also means that it will hopefully protect against malicious actors in between

Oh no, I mean the caps under CPU/GPU sorry

Is it because of the very low ESR of the caps that it appears shorted?

Also faker.js

Because for big SaaS (international) companies, managing your own infrastructure can be hard or borderline impossible. Each country has regulation regarding data centers, each must have disaster recovery and scheduled backup, each must have redundancy to the max, and many other things to consider when hosting on your own infrastructure. Meanwhile you can use that money to pay developers instead of paying someone to wrestle with server stuff.

No, the cat on the left has visible bigger body and somehow that makes me chuckle

It’s cute for the two small enough cats. But its funny when its the big cat

From the FAQ, What is Stremio?

Stremio is a modern media center that gives you the freedom to watch everything you want.

Yeah, I just think that maybe, just maybe, if MacOS is also inspired by UNIX, making a compat layer is not that big of a difference. Because MacOS supports a lot of productivity programs that may attract professionals to Linux too. Mostly adobe suite.

We need to develop darling too

My point is, clear up your mistakes in communication. It doesn’t help anyone to spread misinformation. I hate MS as the linux guy next door, but making false accusations, intentionally or not, will make people stay away from you. Because as I stated, I immediately understand the context just from you sending ToS of a plugin owned by MS. But your accusation is different entirely than your intention.

I never have a problem with your follow up, even if you still did not specify your intention explicitly. At least the ToS is for a plugin that is owned by MS so it provides a clue to what you’re referring to. I have a problem with your original statement.

… A lot of the functionality is in the marketplace but non Microsoft products aren’t legally allowed to use it and you’re not allowed to distribute builds of the plugins.

To put differently:

A lot of the functionality is in the marketplace. Non MS products aren’t legally allowed to use it (1). You’re not allowed to distribute builds of the plugin(s) (2).

See the problem? That statement with the follow up is accusing MS restricting your right to use MS marketplace from non MS product as a problem (1), and THEN accusing that you cannot distribute the build of the plugins from said marketplace (2) which is only true for MS owned plugins.

Yes, hence why I commented that MS never prohibits you from publishing your extension elsewhere. Nor does MS forbid you from using other marketplaces when using their product. It’s like saying valve is prohibiting game dev from publishing their game elsewhere or distributing their game outside of steam. It’s just not true. And MS has all the right to limit their marketplace to their own client too. After all, it is first and foremost, their service for their product specifically. It’s like you’re making an unofficial client for youtube.

Then specify MS plugins. If you only said plugins on MS marketplace, you are blaming MS for things they didn’t do

deleted by creator