I’m developing an application in Castalia 3.2.
How can I change to sleep mode during a time in the application code so that received messages are discarded and then change to listen mode or transmit mode?
Note that I do not want to use backoff neither TunableMAC nor other Mac protocols.
To control the Radio module from the Application module, you can use the control commands which are described in section 4.2.4 of the user manual titled "Dynamically adjusting radio parameters".
If the application module controls the Radio then it's important to be the single point of control, which means the MAC (which normally controls the state of the radio) should not interfere. For this reason you should use the BypassMAC module (which essentially means "no MAC").
Finally, I would advise you to use the latest version of Castalia found at Github. There are several bug fixes and new features compared to version 3.2.
Related
I'm writing a macOS launch daemon (in C++). It works for the most part, except that I am noticing some random crashes via SIGABRT (in the log.)
I've asked earlier about the use of the Core Graphics framework, which it turns out was not allowed in a launch daemon. I removed it, but I still get very rare crashes.
Thus I'm wondering which of the following frameworks am I allowed to use from a launch daemon?
There's no technical restriction on specific frameworks you're allowed or not allowed to link. Merely linking a library will not cause crashes. Some APIs need to be called from specific contexts, such as much of Core Graphics only making sense if a process is part of a windowing session, as you've found out. But even there, some of the off-screen drawing APIs which don't interface with the windowing system directly ought to work from a Launch Daemon context.
If you're seeing crashes calling specific APIs, you'll need to investigate those one by one. If you're seeing "random" crashes, I suspect you have a bug (memory overwrite? multithreading error?) in your code. Note that Apple's toolchain provides a bunch of different diagnostic options which you can use even when not running in the debugger, such as ASan, UBSan, and Thread Sanitizer. These may help you track down issues.
As you've specifically tagged this question with the IOKit tag and it's shown in your screenshot, I'll add that using IOKit from a launch daemon is very common. It's even possible to use IOKit matching events as a launch trigger for the daemon using XPC events/xpc_set_event_stream_handler - this way, your daemon can be started on-demand when a specific (type of) device is connected, for example. (As opposed to starting up at every system boot and consuming system resources even if it's not needed or doing anything.)
API Monitor has a feature to automatically watch for a new process starting and ask if you want to monitor it. However I have not been able to get this to actually work. The only option in the program I can find which seems to be related is the File menu "Pause Process Notifications" option. However, this is disabled which gives me the impressions that it can't be turned off but also that it is supposed to work automatically "out of the box". But whenever I start a new process, nothing happens.
Specifically I'm referring to the feature described here:
Process Notification
API Monitor intercepts process creation and allows you to select the
process for monitoring. Each time a process is created by the system,
a notification window is displayed with options to monitor, skip or
terminate the process. This is especially useful for monitoring
processes with a short lifespan or processes that are automatically
launched in the background. Process Notification can also be used to
monitor applications such as consent.exe (UAC prompt), which run on a
different desktop.
The following screenshot shows an example of the Process Notification
window that is displayed when launching an application that requires
elevation
I've tried both the 32-bit and 64-bit versions of API Monitor (Version 2.0 Alpha-r13) running both as regular user and as admin; makes no difference.
How can this feature be activated?
The specific reason I'd like to use this feature is that I have process A which starts process B, and it is B I need to monitor. A and B each run for only a few seconds so I can't manually get it to monitor fast enough.
Finally after reading through API Monitor forums I found some information. Unfortunately (for now at least) it seems the answer is that this feature no longer works (since Windows 8.1).
As posted on http://www.rohitab.com/discuss/topic/40418-process-notification-on-81/?p=10093378
rohitabPosted 11 October 2013 - 03:38 AM
Due to security related changes in Windows 8.1, the Process
Notifications feature of API Monitor does not work. I will try to
resolve this issue as soon as possible and post a hotfix.
But a later update in 2014 indicated that it hadn't been fixed yet, and seems not to have been since then either.
It was implied that running in a Windows 7 (or 8.0?) virtual machine might be a workaround, or obviously finding another tool which has this capability.
I am trying to add a feature to an Okuma application that can change the operating screens.
I have cycled through the enumerations and I believe the panelgroup I need is 0.
I would like to be able to put the machine into "Manual Mode"
from what I have read in the API Options are Auto / MDI / Manual
Here is one of the variants that I have tried.
It does not throw an error but it does not actually change the operating mode to manual.
If the machine is in Auto/MDI/Manual it will switch to that screen but not the mode.
Maybe I need to access some other API call or maybe I don't actually have API access to put the machine into a mode that code interrupt any other processing G-code..
The ability to change machining modes (Auto / MDI / Manual) is not available from the API.
I can understand why someone may be confused about this point. The way things are worded in the API indicates that changing mode should be possible. That is because in the very early days of API, it was. At one time it was even possible to remote start a machine.
As you know, the Okuma API cannot cycle-start the machine due to safety concerns.
By the same token, changing machine modes while the machine is running in auto would stop / reset the machine. Therefore it is not allowed.
I have a WEC7 powered machine and instead of the Explorer shell I have loaded the Taskman shell instead.
But the SIP (Software input panle) is behaving strange.
When I click a teck box, the SIP is shown for a few seconds and then it is hidden again.
On a WindowsCE 5.0 there are no problems.
Thomas
It may be that the SIP relies on Shell_NotifyIcon being supported and successfully called. This is the API used to include icons in the tray bar. Its implementation relies on a windows with a specific class and title so you may be able to copy the code needed from explorer and include it in your custom version of taskman.
But the best thing to do would be trying to debug the SIP using platform builder.
As far as I know the code for the virtual keyboards is available. I don't remember about the rest of the implementation but, in any case, trying to run it in debug mode may lead to some hints about the issue.
I'm on MacOS Mountain Lion: is there anything like a template to write a service for ML? I use Xcode 4.4.1
The service, in generic terms is a unix daemon, that is, a binary file, executed in background.
You can use Xcode's "command line" utility template to make such a daemon; you still need some means of staring it. In most of the cases, you'll stick to launchd. Check the man page on launchd.plist(5) for more info.
Ok, on the "other" services thing. That are part of NSService, see the docs on Info.plist. You will need to make a "generic" Cocoa application, and then expose its services.
There is also a generic document on services here.