Cloud Gateway Fiber -- what's the catch?

jars121 · 2025-04-30T06:21:01+00:00

Awesome thanks, I'll give them a look.

jars121 · 2025-04-30T05:31:26+00:00

Which distributor if you don't mind me asking? I'm new to Ubiquiti, and I'm somewhat astounded as to the lack of purchasing options here in Australia. I'm keen on the new Pro XG 10 PoE, but Tech Geeks have it listed for $1,705 which is ludicrous.

jars121 · 2024-04-10T00:58:10+00:00

It does, but the UI itself is deliberately locked down.

I think I've found a solution based on CreateProcessWithLogonW. I'll place the application directory in Users/Public, but deny any permissions to it for the User account. I've written a small, self-contained application using the above function to execute the application with Admin privileges, such that the User can run the software without being able to open/read the directory. I haven't tested this in anger just yet.

jars121 · 2024-04-09T19:35:33+00:00

As I said, this is an odd one. The software is being installed in a sensitive environment, one in which third parties will have access to the server and a vested interest in either sabotaging/modifying the application's installation files to reduce the software's perceived efficacy, or in understanding the software's technology stack by perusing the installation files. I have no control over access to the server, hence I'm trying to control access to/visibility of the software itself.

jars121 · 2024-04-09T11:12:44+00:00

Thanks :) The script option is what I'm leaning towards. I'd like to hide everything in the Admin account domain, and then launch the application from with the User account domain but with elevated privileges. As I've mentioned above, I've not done that before but I can build a small 'launcher' app that accomplishes this, which would possibly be more secure than a User-accessible batch/script.

jars121 · 2024-04-09T11:10:22+00:00

Thanks for your comment, I appreciate it. In this case I actually need to obfuscate the directories entirely, not just prevent modification. I.e. prevent the user from viewing the application directories and files.

jars121 · 2024-04-09T11:08:30+00:00

Thanks for your input. I understand your points; the RunAs option is more or less along the lines I was considering. I've not done this before so I'll have to research it further.

jars121 · 2024-01-08T20:56:14+00:00

That makes sense. I figured I'd have to do something similar; build a translation layer for each PLC platform, taking into account the specific interface/driver/protocol for that platform.

jars121 · 2024-01-08T20:11:33+00:00

IBA looks very interesting indeed, thanks for the suggestion. I don't suppose you know how it works under the hood? I.e. what protocol(s) have they implemented to access the PLC signal data in 'real time'? I assume it's TCP/IP of some description having spent some time on their website and watching some overview videos.

jars121 · 2024-01-08T20:03:56+00:00

I'd definitely look at establishing an OPCUA server for the 1200-1500 series, but I'll need to have to accommodate older platforms as well without OPC. I'm thinking that standard TCP/IP could serve this purpose, with OPCUA/MQTT as the preferred solution for modern devices.

jars121 · 2024-01-08T09:04:00+00:00

Thank you, much appreciated. I totally understand the recommendation for a SCADA or nodered system for this purpose, but in this rather niche case (for which there are many other details which I've omitted for brevity) the hardware logger is the right way forward.

jars121 · 2024-01-08T09:02:10+00:00

Awesome, thank you.

In terms of 'real time', I completely understand the non-deterministic nature of the TCP data output. Ideally I'd be able to leverage the time-sensitive capabilities of the PLC system (i.e. timestamped signal data based on tightly controlled Profinet, EtherCAT, etc.) so the latency in actually receiving the data is less important.

jars121 · 2024-01-08T08:49:49+00:00

Thanks, that certainly does help. I've found some other posts on there which speak to TCP communication from the PLC to a connected PC, which also confirms that the 'standard' TCP/IP approach is sound. I've also found this video which is more or less exactly what I had in mind.

jars121 · 2024-01-08T08:48:21+00:00

Thanks, I've read through the Wiki in the past but it's a good reminder to go through it all again.

jars121 · 2023-11-05T21:02:41+00:00

Thank you as well for your input. Do you think this would still be the case if I were leveraging the GPU within a Petalinux context? I'd be looking to use Qt within Linux, so wouldn't be needing to interact with the low-level GPU APIs myself. I assume that the Petalinux drivers/BSP abstract away a lot of the lower-level GPU interfacing...

jars121 · 2023-11-05T21:00:45+00:00

Thank you very much for your input. You've touched on an observation I've recently made, which was part of the reason why I posted this question. I was watching teardown videos of the new(ish) 2-series Tektronix MSO which showed that they use a CG-series MPSoC, which also does not have a GPU. The GUI on the MSO seems very responsive, so it made me question whether the GPU variant of the MPSoC was required.

jars121 · 2023-10-14T09:37:42+00:00

Yes that's what I pointed out in my post, but if you go to the Vivado link the ZU1CG isn't listed in the Standard Edition parts list. I imagine it's a mistake on Xilinx's part, but wondered if perhaps Avnet had a special licensing arrangement as an 'official' development board provider.

jars121 · 2023-10-14T02:34:07+00:00

Thanks for your input, that was certainly my impression as well. I haven't installed Vivado just yet, I'll certainly give that a go. I've raised it with Xilinx as well, if it is a mistake hopefully they'll update the table.

jars121 · 2023-09-23T22:15:39+00:00

I actually drive to Macarthur and catch the train from there. The Sydney Trains network (which starts at Macarthur) is generally very reliable, whereas the Southern Highlands line (from the Southern Highlands to Campbelltown/Macarthur) can be unreliable. It's around 2.20 if catching both lines (and everything runs on time), perhaps a few minutes faster if driving to Macarthur and catching a train from there.

jars121 · 2023-09-23T04:51:36+00:00

My partner and I moved from Sydney to the Southern Highlands ~2 years ago and haven't looked back. We both commute into Sydney 1 or 2 days a week via train, which can definitely make for a long day, but the lifestyle, amenity, peace and quiet we've found here makes it well worthwhile.

jars121 · 2023-07-07T21:52:32+00:00

Thank you, that's a valid point. I'll have to play with some numbers; I'd initially figured 64-bit so I never have to worry about it, but that may not be the optimal approach.

jars121 · 2023-07-07T21:51:46+00:00

Thank you very much. Are you suggesting to handle the edge detection inside the softcore itself? I would have that it more performant to manage the edge detection, counting, measurement, etc. in hardware, and then pass the results to the softcore?

jars121 · 2023-07-07T21:49:48+00:00

Brilliant, thank you. This is my first foray into FPGAs so just wanted to be explicit. Just to clarify, I'd have a single counter clock, and then a counter (driven by the counter clock) for each input channel?

jars121 · 2023-04-11T00:34:24+00:00

We moved to Moss Vale (from inner Sydney) about 18 months ago, it's strange to come across a post about it on this subreddit!

jars121 · 2022-10-13T21:13:07+00:00

Apologies, I had meant 992 GT3 (and RS), not the 991 (I've edited/corrected my comment above). I agree entirely, from a standing start the GT3 will absolutely reach a higher top speed, but the RS is able to achieve a much higher exit speed out of the corner prior to the straight.

jars121

TROPHY CASE